ULC provides five kinds of models:
The dynamic environment of Smalltalk enables the generic implementation of all three of these models. UlcModel serves as data accessor for the UI. All widgets that can take their values from UlcModel have a string attribute called (form)AttributeName. This string is the attribute name of the domain model instance behind UlcModel. For UlcModel to function, all domain models must implement set and get methods conforming to standard Smalltalk conventions. When the UI requests a certain value from UlcModel, formAttributeName is passed in. UlcModel sends this string to its domain model as a message and answers whatever the domain model answers.
The implementation of UlcModel in Smalltalk saves the developer from having to implement the mapping of formAttributeName to domain attributes. To use UlcModel, do the following:
It is always possible to follow the Java approach and create the necessary adapters as subclasses of the appropriate UlcModel subclass. The explicit message-sends in the adapter would eliminate potential problems that might occur at packaging time. All get and set methods used in UlcModel adapters must be either explicitly included in the packaging instructions or referenced (that is, sent) in code that gets packaged (see About model-based widgets for more details).
If a widget uses a form model, it will not receive widget-specific events. This is because the form model handles all changes to its widgets on the UI side to minimize traffic. Widgets that must trigger special events on the application-server side should not be linked to a form model.
Form Models now preload all data for their clients reducing the number of round trips required to populate the view.
For usage examples, see Using ULC nonvisual parts.