These classes provide a convenient means of storing your application data and keeping it separate from the user interface, allowing you to change the interface components while minimizing the impact of the application logic represented by linked properties and property change listeners. For example, instead of relying on the user interface components to hold your application data and linking to properties of list boxes, radio boxes, and text fields, etc., you can instead store your data in one or more ObjectData, StringData, IntegerData, and other components from this package. These objects act as the application data model for your user interface. Then, link your UI components to the objectData property of the data object, rather than linking various user interface components together directly.

For example, a common element of user interfaces built to access the SAS system are a list box selector for a SAS library (attached to a LibraryListInterface) , then a list box selector for a SAS data set (attached to a DataSetListInterface), and a TableView for browsing viewing the data set. The current selection in the library list box (libraryListBox1.selectedItem) is set as the library property of the SASFileList object (dataSetList1.library). The current selection from the data set list is linked to the dataset property of a DataSetInterface object dataset1, which serves as the model for the TableView. See the figure below which shows the UI elements, their models, and the two property links used to connect the objects together.

However, if other elements of the interface wish to link to the selected library name or the selected data set name, they must link directly to the listbox UI components. This makes it much more difficult to change the User Interface because many links must be recreated if either of the list boxes is replaced with a different component.

A better design would use one StringData object (called libraryName) to store the selected library name and another StringData object to store the selected data set name (called datasetName). Then, other components would link to either libraryName.text or datasetName.text. For example, if you wish to add a label to the table view, you would link datasetName.text to label1.text, rather than linking the datasetListBox1.selectedItem to label1.text. You can also make the datasetName component serve as the model for the label, instead of using property linking.

if you then decide to change the list boxes to Choice components or ComboBox components, you need only update two links; the rest of the application remains unchanged. The diagram below shows the linking between the UI components and the models used to store the application data (libraryList1, libraryName, datasetList1, datasetName, and dataset1.)

This may look significantly more complicated, but it actually only two new components and two new links. However, now you are free to change the user interface. For example, you could replace the data set selector from a ListBox to a ComboBox (or a RadioBox or a Choice component or a TreeView) with minimal impact on the rest of the application, because there is only one link from the ListBox which has to be recreated if you delete the ListBox and replace it with a different UI component. You only need to recreate the single link between the selector.selectedItem and datasetName.text properties; the rest of the application will continue to work as before.