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:
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:
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: