Day: 17 March 2010

Choosing a Model/Event Pattern

The following diagrams show different implementation patterns of models and corresponding events, as typically used in the UI. Depending upon your needs, you can use the following tables to decide which pattern to implement. The patterns are split into model patterns and event patterns. Not all combinations of the patterns make sense, but patterns can be combined to fulfill your unique requirements. At the end I make some recommendations. Model Pattern 1 - Automatic Event Firing With the above pattern every change to the model results in an event being fired. Typically if the focus of a text field is lost, the model gets set (in Eclipse RCP perhaps using databinding). Any views that show this model attribute get notified and update themselves. Works well for cases where multiple views of the same model need to be continuously up to date. A big disadvantage is the number of events which get fired. You also need to watch out for cyclic dependencies whereby an event updates a second view, and that update fires another event which updates the first. UI performance can suffer with this pattern, because its granularity is simply too fine.   Model Pattern 2 - Manual Event Firing This pattern lets the caller (typically the controller) fire an event after it has finished updating all parts of the model. Typically the controller performs any validation of multiple fields, may call the server and when everything is good, updates the UI's model. An example might be when an input…

Read more