PCS release 16.3.5 introduced a brand new home-grown web form in replacement of the Frevo based web form. I had an opportunity to work with the new web form for a customer demo just before its release. This post intends to describe my first impression with the new web form and introduce some new features that I learned from my first hands-on experience. I intend to write a second post on the same subject but focusing solely on look-and-feel customization using a custom CSS file.
I have no experience with Frevo Web Form in PCS but I am familiar with web form development in general. The new Web Form editor looks intuitive enough for me to be productive immediately. Out of the box, it provides all the most commonly used web form controls such as text field, buttons, check box and etc. Some of the more interesting controls are Table, Tab, Repeatable Sections and Panel.
The new Web Form supports some general features as one comes to expect, such as drag-and-drop, basic property and style editing. So over all, the initial construction of a form is very easy. As I progressed into building my form, the following areas of the new Web Form have caught my attention.
Out of the box, Web Form uses row based vertical layout, see Row 1 and Row 2 in the above image. Each row can contain multiple columns (Row 3) (via drag and drop). For a more sophisticated layout, a Panel control is provided. The Panel control can be set to use vertical layout (single column multiple rows, left and right panel in the picture above) or horizontal layout (single row multiple columns, button panel with orange background). By using multiple panel controls, most commonly used form layouts can be achieved.
Each control that takes input from users requires data binding. By default, Auto Binding property is turned on (see image above), which means each time a control is dropped, a corresponding form data object is created. Automatically created form data object is deleted when the corresponding control is deleted. Users can turn the auto binding feature off if so desired, in which case, a binding object must be created manually.
The binding object for a table control must be an array of a data object which contains properties. After a table control is create, columns can be added. To display data or accept user input, a control must be added to each column. The control in each column is then bound to a property of the data object.
An interesting feature related to the Table Control is the use of a REST connect to retrieve data to initialize the form. This feature needs to be explicitly turned on (see image above). Then, a REST connector (must be configured prior) can be selected and additional configuration (such as its resource name, methods and query parameters) must also be set.
The final step is to map the properties of the REST response message to the controls in the table cells (see above image).
Dynamic behavior of a web form is achieved through events (see image above). An example of such dynamic behaviors is hide some controls when the form is initially loaded and show these hidden controls when a user enters some information in another control. Most commonly used events are available out of the box.
After an event is selected, its behavior can be specified through the edit button. The behavior is defined as a combination of condition statements and actions. The above image shows a simple definition that says, when the account number entered is greater than 100,000, disable Account Name input field in the form. A more complex behavior can be defined through if-else if-else combination. Compound conditions are also supported.
The Type field in the condition statement can be Constant, Data Definition(form data objects), Control and Function (mostly date time related functions only).
The new web form provides a feature named Presentations. A Presentation is a UI rendering of the form data objects. When a web form is first created, a default presentation called Main is created. Additional presentations can be added later on. One use case for such a feature is that the main presentation can be used for entering data and other presentations can be added for viewing data (read only rendering).
In a User Task properties editor (above), a form and one of its presentations can be selected.
A limited set of styling properties (see image above) can be set for the controls. For more sophisticated styling, a style sheet file can be specified in the form (see image below). The style sheet file should contain all style class definitions that are used for individual controls in the form.
See the above images for some available styling properties for controls. The right image shows that a style class (defined in the custom style sheet at the form level) can be specified for finer grained styling. However, simply define a custom style class is usually not sufficient to change the look of a control. This is because your custom style class is usually overridden by an out-of-box style class with higher specificity. A separate post will be posted to demonstrate how to make the custom style classes work in the new Web Form.