Ultra Light Client Guide and Reference


Building ULC applications visually

Building an application with ULC parts follows the same process as building any VisualAge application. However, important differences exist, as follows:

Connections. Unlike standard VisualAge parts where the user interface is expected to run on the same machine as the application, ULC parts are designed so that user interface and application can be running on different machines connected through a network. ULC parts are therefore optimized to reduce the amount of network traffic. This approach requires discipline on the part of developers when making connections between widgets and parts to ensure that only necessary updates are sent across the network.

ULC parts do not signal events for state changes (no self event). As a result, attribute-to-attribute connections have limited utility; they run only once, sent as initialization messages in the #ulcBuildInternals method.

Use event connections to explicitly set the contents of widgets. Each ULC part has a well defined set of events that can be used to make event-to-action or event-to-script connections.

Layout. ULC parts use a different layout scheme than standard VisualAge parts do. You arrange ULC parts using a grid-based layout scheme. This scheme lays out widgets in a portable way independent of actual widget size. For more information about layout, see ULC layout.

Converters. ULC supports local validation and formatting of user input in the UI Engine. The ULC Field part supports the following ULC converters:

ULC converters substitute for the standard VisualAge converters, which would require round-trips between the UI Engine and the application server. Using ULC converters to validate and format data in the UI Engine avoids those extra round-trips. You can extend this set of ULC converters using a process similar to that described in Implementing ULC objects.

Standard VisualAge converters should be used only when local validation in the UI Engine is not possible. You cannot do this visually; you must write a method to pass the object to be converted to the converter and then set the contents of the ULC widget part with the converted object.

Enablers. It is common practice in GUI development to enable or disable a widget based on the state of another part. ULC parts support enablers, whereby traffic between the UI Engine and the application server is not needed to enable or disable a widget.

An enabler informs its registered widgets that it has changed its state, and effects the change of the enable/disable state of these widgets. These widgets can serve as enablers: UlcField, UlcFormModel, UlcTableModel, UlcList, UlcTable, UlcTree, UlcToggleButtons, etc.. For example, you can use the UlcTable as the enabler for a UlcButton. The UlcTable object will tell the button to change its state to enable whenever there is a selected item in the table.

Enablers can be concatenated with the help of these classes: UlcAndEnabler, UlcNotEnabler, UlcOrEnabler, and UlcXorEnabler.

For an example of visual composition, see Building the To-Do List with ULC.


[ Top of Page | Previous Page | Next Page | Table of Contents | Index ]