Melting Groups in the Display Mode of the GUIBB Form@GL2.0:
A form that is based on the GUIBB Form@GL2.0 consists of single form elements that are arranged in a rigid grid. A form element may either be a standard element, a button element (normal button, toggle button, or button choice), or a button row. Their position is specified by coordinates, given by the start row, end row, start column, and end column. Currently, the following standard elements are supported:
- Check Box
- Checkbox Group
- Drop Down
- File Download
- File Upload
- Formatted Text Edit
- Formatted Text View
- Input Field
- Link To Action
- Link To Url
- Progress Indicator
- Radio Button Group
- Section Header
- Text Edit
- Text View
- Threshold Slider
An example of these UI elements in edit mode of the GUIBB Form@GL2.0 is shown in Figure 1; the same example in display mode is shown in Figure 2.
Figure 1: UI Elements in a GUIBB Form@GL2.0 in edit mode
Figure 2: UI Elements in a GUIBB Form@GL2.0 in display mode
There are often fields in forms that belong semantically together and are therefore positioned one after the other into the same row of the form. In the following such fields are called “Melting Group”. Typical examples for such cases are addresses with zip code and city, street and house number, phone numbers with area code and extension, amount and their currency, or numbers and their measure unit. The involved standard elements in such a case are mostly input fields, drop-down list boxes, and text views.
In edit mode the layout of fields that are positioned in the same row is usually non-critical. Input fields and drop-down list boxes are rendered with a border, i.e. their boundaries given by their coordinates are clearly visible to an end-user. If a text view is used in combination with input fields or drop-down list boxes, the text view contains mostly a descriptive text. The text view is normally placed behind the input field or drop-down list box in this case, without further fields behind the text view. Therefore, text view borders are not required.
However, in display mode the layout of fields that are positioned in the same row might be ugly if the fields are supposed to behave as a Melting Group. The reason is that neither input fields nor drop-down list boxes nor text views are rendered with borders. Since the form layout is a rigid grid each cell of this grid has the same size, dependent on the available horizontal space but independent of its cell content. If there are, for example, four grid columns reserved for a street and one column for the house number there is probably a large distance between the street and house number in display mode, and it’s not visible and understandable for the end-user why this is the case.
Conditions for Melting Groups:
Unfortunately, there is no grouping mechanisms in the Form@GL2.0 that allow denoting Melting Groups, i.e. there is no corresponding meta-data available. The introduction of new meta-data for that purpose is not desired since it would result in either additional configuration effort or additional programming effort in the feeder class. Hence, a smart algorithm must be applied to identify Melting Groups automatically and that avoids the horizontal spacing between their fields. This algorithm is based on the following conditions:
- A Melting Group consists of at least two form standard elements.
- Only input fields, drop-down list boxes, and text views are allowed in a Melting Group.
- No gaps with respect to the field coordinates are allowed between the fields of a Melting Group.
- All fields of a Melting Group must have the same height of one row.
Rendering of Melting Groups:
The desired appearance of Melting Groups in display mode is very different from that in edit mode. In edit mode the Melting Group fields are rendered as normal fields with coordinates in the surrounding rigid form layout grid. From this perspective it is not obvious that there are Melting Groups at all in edit mode. However, in display mode the fields of a Melting Group have to move close together and look text-like. Hence, there are several specialties to take into account for rendering the display mode:
- The Melting Group fields will be rendered in a separate layout container that has a non-rigid layout and that is embedded in the surrounding form layout. In this way, the correct formatting of the single fields (e.g. regarding decimal notation, points, date format, time format, etc.) is ensured. However, an unfavorable consequence is that always the last field in the layout container will be cut-off first if there is not enough horizontal space and not all fields at once as it is the case in a form layout.
- The width of the single Melting Group fields will not be explicitly set anymore to the configured value since this could result in too large horizontal spacing between the fields.
- Since successive fields without fixed field width would be rendered without horizontal spacing in a grid layout the property ‘paddingRight’ of the grid data of those fields has to be set to a non-zero value that have another field as right neighbor in the Melting Group. The padding will be set to four pixels in this case since this is the default right padding that is used for successive fields in a flow layout.
- A new property ‘displayOnly’ will be introduced on input fields and drop-down list boxes. It will be set true in display mode. In this way the input fields and drop-down list boxes will be implicitly rendered as a text view by WD ABAP and setting the properties ‘readOnly’ and ‘displayAsText’ need not to be set true any longer.
Figure 3 and Figure 4 show an example for a form with Melting Groups in edit mode and display mode, respectively. In the latter case the Melting Group fields are rendered in a layout container with a grid layout and the property ‘displayOnly’ is set true for input fields and drop-down list boxes.
Figure 3: Melting Groups in a GUIBB Form@GL2.0 in edit mode
Figure 4: Melting Groups in a GUIBB Form@GL2.0 in display mode