Ultra Light Client Guide and Reference

Working with Form Model parts

The Form Model part enables changes made in the UI to be deferred and sent to the application only when explicitly flushed. Form Model parts are typically used with standard business domain objects. The following example of a composite part shows the essentials:
Name composite

The connections between the Entry Field parts and the Form Model part are all the same: between the formModel attribute of each field and the self attribute of the Form Model.

What makes the correct information appear in each field is its formAttributeName setting.

The connection to the SomeName part associates the Form Model with a "real" instance of Name: between the model attribute of the Form Model and the self attribute of the SomeName part.

Note the use of valueHolder rather than self. Name is a Smalltalk class that follows standard VisualAge protocol. When SomeName was dropped, ULC automatically wrapped it in a non-ULC-object wrapper of type UlcNonUlcObject. This class is related to the ULC variable discussed previously. The square brackets surrounding SomeName indicate that it is neither a true ULC part nor an instance of the Name class itself.

This name view is actually a ULC composite part. To (re)use it in other ULC visual parts, two features of the Form Model part must be promoted: the saveInput action and the inputSaved event.

Now suppose the name view is added to a ULC visual part that looks something like this:
Name view

The name composite has been dropped into the upper cell of a Vertical Box part. A Close button occupies the lower cell. For this trivial example, we use an alert to indicate that the data has been sent. Here is how the connections go:

  1. The action event of the Close button is connected to the promoted saveInput action of the name composite. This triggers the explicit flush mentioned previously.
  2. The promoted inputSaved event of the name composite is connected to a script called signalAlert, which creates and shows a confirmation that the event occurred. In a more robust application, the inputSaved event would trigger some other UI action, for example, the synchronization of another view.


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