When model and view collaborate, data transfer is usually required in both directions, from model to view and backwards.
Consider a simple text field. The model for a control implements a com.sun.star.form.component.TextField service. This means it has a property Text, containing the current content of the field, and a property BackgroundColor specifying the color that should be used as background when drawing the text of the control.
First, if the value of the BackgroundColor property is changed, the control is notified of the change. This is done by UNO listener mechanisms, such as the com.sun.star.beans.XPropertyChangeListener allowing the control to listen for changes to model properties and react accordingly. Here the control would have to redraw itself using the new background color.
In fact this is a common mechanism for the communication between model and view: The view adds itself as listener for any aspect of the model which could affect it, and when it is notified of changes, it adjusts itself to the new model state. This means that the model is always the passive part. The model does not know its views, or at least not as views, but only their role as listeners, while the views know their model.
On the other hand, if the view is used for interaction with the user, the data needs to be propagated from the view to the model. The user enters data in a text field, and the change is reflected in the model. Remember that the user sees the control only, and everything affects the control in the first step. If the user interacts with the view with the intention of modifying the model, the view propagates changes to the model.
In our example, the user enters text into the control, the control automatically updates the respective property at the model (Text), thus modifying the document containing the model.
|Content on this page is licensed under the Public Documentation License (PDL).|