FWD » Core Development » User Interface

In OE, the SORT attribute value cannot be modified once the widget is realized, resulting in the following warning message being displayed: Unable to set SORT because the COMBO-BOX widget cb has been realized.
In FWD, however, no warning is shown, and debugging indicates the attribute value is applied to the widget.
This does not mean, though, that sorting can be freely switched on and off in FWD at any time.

Let’s examine the following program:

   DEFINE VARIABLE cb AS CHARACTER VIEW-AS COMBO-BOX LIST-ITEMS "c", "b", "a".
   DEFINE VARIABLE srt AS LOGICAL VIEW-AS TOGGLE-BOX.
   ENABLE cb srt WITH FRAME f.

   ON VALUE-CHANGED OF srt DO:
     ASSIGN srt.
     cb:SORT = srt.
   END.

   WAIT-FOR CLOSE OF CURRENT-WINDOW.

In this program, an initially unsorted COMBO-BOX is created, initialized with unsorted items ("c", "b", "a"). A toggle button is also included, allowing the user to switch sorting on and off.
In FWD, the items are initially displayed unsorted. When the user presses the toggle button for the first time, the list becomes sorted. However, switching sorting off with the second button press does not unsort the list, which remains sorted.

The warning part should be straight-forward, just check if the widget is already realized through _isRealized() and use ErrorManager.recordOrShowWarning(). The more interesting part arises when changing SORT multiple times.

I observed in 4GL that changing "sort" to true or false before the widget is realized does not impact the internal item order because :LIST-ITEMS returns the initial set for both options. However, when the widget is realized, :LIST-ITEMS is updated which means:

1. If the widget is not realized, each :SORT assignment does not influence the item order
2. Only after realization, the last :SORT assigned value kicks in and if true, the items are ordered

What FWD currently does is to immediately sort the items if set on true. When false, it just updates config.sort, but does not rewind the list to its initial form.

The logic is flawed. We should only sort when the widget becomes realized. We can do it:

1. On the client
   • This is the place where we now exactly when the widget is realized. The sorting can be done on the client, but this has numerous performance drawbacks. I've calculated that every time the server wants to get the list items, a minimum of 1 flush (client round-trip) attempt will be necessary in order to get the updated list. The current implementation on the server does not flush when getting the items, so each such usage needs to be changed.
2. On the server
   • This aligns with the current implementation, but we still need to sort the list only when the widget becomes realized, which we don't know because it happens on the client. This sounds like aspect work, but it would be applied every time a message is received from the client, which is another big performance drawback.

Currently there are 4 classes which extend ControlSetEntity: ComboBoxWidget, SelectionListWidget, RadioSetWidget and BrowseColumnWidget. The last brings its own setSort() implementation. RadioSetWidget does not support the sort attribute in 4GL, but since it extends this parent class in FWD, we'll consider this as an enhancement. In addition, testing showed that combo-box and selection-list has the same behavior regarding to sorting items.

Hynek: Please advise on how we should tackle this.

Razvan, try the following.

Sort on the client during realization. After you sort mark the sorted items field on the config (items) as dirty with ConfigManager.markFieldsDirty. This will mark the config fireld to be sent back to the server when the server-client down call finishes. Do not do pushWidgetAttr after sorting the items, this server upcall would be redundant.

Please let me know it works.

Hynek Cihlar wrote:

Code review. Just one more minor point. Please move sort out from the config class. The config classes are a kind of lean DTO and should not contain application logic.

The sort method was placed in this specific config subclass (ControlSetConfig) because it directly references several fields unique to that subclass, and this subclass is the only common point shared among the three widget types (ComboBox, RadioSet and SelectionList).

Although the widgets implement a common interface, placing the field-referencing logic there — even as a default method — is not feasible, as it would tightly couple the interface to implementation-specific details.

Vladimir Tsichevski wrote:

Although the widgets implement a common interface, placing the field-referencing logic there — even as a default method — is not feasible, as it would tightly couple the interface to implementation-specific details.

A static method in ControlSetEntity would do it I think. In the past we spent a lot of effort to remove all the logic out of the config classes. Given the history putting it back would not make sense.

Testing that passed:

• ChUI regression testing
• Hotel GUI + 2 customer app smoke tests
• selection-list, combo-box and radio-set SORT tests taken from the testcases project. Some which were failing with trunk are now passing with 10100a.

If this is enough, we should merge 10100a.