Most ULC widgets support two types of model-widget relationship.
In the first type (subclasses of UlcFormComponent), every widget
has a built-in model and provides an API for accessing and changing the
model:
For example, a field has a text model and methods setText: and getText. In addition, the widget provides methods for specifying the visual appearance of the user interface element, for example, what font to use or how many characters to display.
The second type uses an external model that is a separate object; this
model can be shared between different widgets:
With this type of model-widget relationship, the application creates and configures both model and widget and then updates only the model. To retrieve changed data, the application asks the model for it, not the widget.
An example of this correspondence is the table widget and table model pair. The table model implements a two-dimensional data structure with rows and columns. The UI half of the object contains a cache so that data access requests of the table widget can be fulfilled immediately. If the cache does not contain valid data, the table model returns placeholders and asynchronously requests new data from the application half object. When this data arrives, the dependent widgets are notified and updated.
Synchronization of the two halves of the table model is configurable. Its notification-policy property gives you fine-grained control over when updates are sent from the UI to the application.
The form model is another example of the model-based API. A form model represents a set of named and typed attributes, similar to a heterogeneous dictionary. Most simple ULC widgets can be initialized with a form model and attribute name. Fields can be used on string attributes, check-boxes on boolean attributes, and groups of radio buttons on enumeration-type attributes. These widgets ignore their built-in model but track changes and allow updates of the named attributes of the specified form model.
As with the table model, the form model's notification-policy property gives you fine-grained control over when updates are sent from the UI to the application.