When migrating forms of the ui Module to the forms Module, consider the following:
- In migrated forms, the initialization of local variables is moved to the form constructor.
- All listeners with their properties are removed (any validation, handle, action properties are lost).
- If you are using the form in a document or a user task, the usage expressions are not migrated (they will still use the original form)
Migration creates a backup file of all forms so you can refer to it to identify data that was not migrated.
To migrate forms from ui to forms, do the following:
- Prefix all data types from the ui module: This will prevent name clashes with the names in the forms module:
- Go to Project > Migrate LSPS 3.1 Projects.
- In the Migration dialog, select the projects and click Next.
- Select Add ui:: prefix (unselect any other irrelevant options) and click Finish.
- Import to your Modules the forms Module: In GO-BPMN Explorer, double-click Module Imports, click Add and double-click the forms Module in the Standard Library node.
- In GO-BPMN Explorer, right-click either the form or the Module with the forms you want to convert and select Convert to FormComponent.
- When converting all forms in a Module, define the names of the forms in the displayed dialog box.
Changes in Forms
Main Benefits
- No fixed event-processing lifecycle: the user specifies the behavior with actions when they see fit. Part of the behavior, such as, Submit and Refresh, is now defined in methods of the Forms record. Component specific actions, such as, validation, became methods of the Form components.
Note: In UI forms, form actions are defined as callback expressions: the user must be aware of when the callbacks are used. This depends on the event-processing lifecycle and related mechanisms, which are relatively complex.
- Simple changing of the tree component dynamically (changes of the tree on runtime) since Form components are Records with methods (ui forms are functions)
Improvements on Components
- Grid and Table support row selection: the form can handle the row-selection event.
- Popup is now defined out of the form component tree and can be reused.
- TextField, DecimalField and DateField substitute the ui::TextBox component.
- Chart design has been improved significantly.
- Pie Chart can now be rendered as a Donut chart.
- Charts are now more flexible and dynamic: you can add data points on runtime without reloading the charts.
New Components
Removed Components
The approach eliminates the need for the following components:
- ui::ViewModel: the "undo/cancel" capability can be now achieved with Record Change Proxies in more controlled and transparent manner (the proxy mechanism is a generic modeling mechanism; an example is available in Quickstart.
- ui::Container and public-listener and registration-points mechanism: forms can define public methods to allow access from "outside".
- ui::Conditional: substituted with the setVisible() method of components.
- ui::Geolocator: replaced by the Forms.detectLocation() method.
- ui::Message: the user can now display the messages on failed validation easily in the entire form.
Missing Features
- Inserting a new value in the Combo-Box component
- Saving of documents and to-dos
- Support of Custom components in PDS (It is still possible to implement your component and create it from the Expression Component as a Record instance.)
Feature | forms | ui |
General modeling approach | form behavior defined by expressions and their methods | behavior defined in GUI of the forms editor (listeners) |
Properties | partial support by the GUI of the form editor; fully supported as expressions | support by the GUI of the form editor |
Actions | partial support by the GUI of the form editor (if defined directly on the form component); fully supported as expression anywhere else | Predefined lifecycle with actions; user defines callbacks for the lifecycle (they must be aware of the lifecycle mechanism, which is relatively complex) |
Values | Given either by binding to variable, data source or internal value of the component. | By binding to variable. |
Iterating values (collections in UI) | By data providers. | By iterators which are usually local variables. |