In the previous chapter we looked at the implementation of a non-trivial application composed of several application components. If you had a closer look at the code fragments in chapter 3 you probably realized that even for a simple application component quite some boiler plate code was required to make it work. The presentation model contains infrastructure code that takes care of property listener handling, e.g. registering property change listeners and distributing property changes to listeners. It also has to delegate most property requests to the business object. These tasks can easily be extracted into a base class and handled generically.
In addition, the base class can provide infrastructure such as:
- Creation, proper initialization, and management of a hierarchy of application components: the root application component is responsible for property change listener management, i. e. all sub-application components delegate to the root application component rather than managing this all over the hierarchy, which simpifies debugging a lot.
- Breaking cycles: the execution of a property change listener should not trigger (directly or indirectly) the same property change listener.
- Undo/Redo support: The presentation model is a Java bean and all state transitions are performed by property changes. Hence, undo/redo support is really easy to implement on a generic basis. The abstract presentation model just records all property changes and can undo or redo them on request.
This leads to a simple presentation model framework with only a few hundred lines of code. It is independent of any widget library, although the current implementation includes configurable table and tree models based on the ULC widget library. They should be easily replaceable by model implementations of some other component library.
The view code is even more cumbersome. Despite being pretty straightforward way too many lines of code are needed for implementing the view. How can this be simplified?
- Creating the layout can be accomplished by using either a declarative or programmatic approach. For the declarative approach one would need some XML schema for defining the components and layout of the user interface. At run-time, an interpreter creates the UI based on the XML description. The programmatic approach requires at least a layout class which is tailored to form-based user interfaces. Examples are JGoodies Forms or the new form infrastructure in UltraLightClient ‘08.
- Connecting the widgets to the presentation model and vice versa can be vastly simplified by utilizing some binding infrastructure. We will talk about binding in the next chapter.
- The remaining tasks are easy to implement and require little code: proper initialization of the view (most initializations are triggered by the presentation model anyway), forwarding events to the presentation model that are not yet taken care of by the binding infrastructure (e.g. button actions), and reacting to changes in the presentation model (e.g. enabling/disabling portions of the user interface accordingly).
Now lets have a look at the code for the example from chapter 3. For the programmatic layout of the form I used a simple form layout class.
The core code for the presentation model looks almost like the example given in chapter 3 (boiled down to three model properties for the sake of simplicity). Thanks to the presentation model framework, the number of lines of code is cut almost in half (now less than 150 lines of code incl. comments and blank lines).
public class SimpleFormPresentationModel extends AbstractPresentationModel {
private Person fPerson;
private ErrorList fErrorList;
public final static String PERSON_NAME = "person.name";
public final static String PERSON_FIRST_NAME = "person.firstName";
public final static String ERROR_LIST = "errorList";
private final static String[] PREFIXES = {"PERSON", "UNIVERSITY"};
public SimpleFormPresentationModel() {
fHasChangedEnabler = new ULCHasChangedEnabler();
}
public void basicInit() {
fErrorList = new ErrorList();
fireAllPropertiesChanged(PREFIXES);
addPropertyChangeListener(this, getAllPropertyNames(PREFIXES));
super.basicInit();
}
public void update(String propertyName, Object oldValue, Object newValue) {
if (propertyName.equals(PERSON_FIRST_NAME)) {
validatePerson(PERSON_FIRST_NAME);
firePropertyChanged(PERSON_NAME, getPersonName(getPerson()));
}
}
public Person getPerson() {
return fPerson;
}
protected void setPerson(Person person) {
fPerson = person;
fireAllPropertiesChanged(PREFIXES);
fHasChangedEnabler.reset();
setFocusToProperty(PERSON_FIRST_NAME);
}
public String getPersonName(Person person) {
return person != null ? person.getFirstName() + " " + person.getLastName() : "";
}
}
Some functionality is based on conventions which can be customized by overriding the appropriate methods. Properties are “exported” by declaring the path as a string constant, e.g. PERSON_NAME. The business object is referenced by an instance variable. The prefixes of the property constant names are kept in the string array PREFIXES. This way, properties can easily be retrieved by reflection. This is used to fire property change events or register event listeners for all properties.
Theview class is also reduced to half the lines of code. This is mainly due to the form layout class and the binding infrastructure.
public class SimpleFormPane implements IPropertyChangeListener {
private FormLayout fFormLayout;
private ULCBoxPane fFormPane;
private ULCTextField fName;
private ULCTextField fFirstName;
private SimpleFormPresentationModel fFormPresentationModel;
private Binding fBinding;
private Color fErrorColor = new Color(255, 0, 0, 192);
public SimpleFormPane(SimpleFormPresentationModel formPresentationModel) {
fFormPresentationModel = formPresentationModel;
}
public ULCComponent getPane() {
if (fFormLayout == null) {
createForm();
fBinding = new Binding(fFormPresentationModel);
fBinding.bindText(PERSON_NAME, fName);
fBinding.bindText(PERSON_FIRST_NAME, fFirstName);
}
return fFormPane;
}
private ULCBoxPane createForm() {
if (fFormLayout == null) {
fFormLayout = new FormLayout(FormLayout.NULL_RESOURCE_RESOLVER, "PersonForm");
fName = new ULCTextField(20);
fFirstName = new ULCTextField(20);
fFormLayout.addComponent("Name", PERSON_NAME, "Name:", fName, true, "1EE");
fFormLayout.addComponent("FirstName", PERSON_FIRST_NAME, "First Name:", fFirstName, "1EE");
fFormPane = new ULCBoxPane(true);
fFormPane.add("et", fFormLayout.getPane());
}
return fFormPane;
}
public void update(String property, Object oldValue, Object newValue) {
if (property.equals(LOADED)) {
fFirstName.requestFocus();
fLoadButton.setEnabled(!(Boolean)newValue);
} else if (property.equals(FOCUS)) {
ULCComponent component = fFormLayout.getComponent((String)newValue);
if (component != null) {
component.requestFocus();
}
} else if (property.equals(ERROR_LIST)) {
ErrorList errorList = (ErrorList)newValue;
for (at.diefaehre.argo.util.validation.Error error : errorList) {
ULCComponent component = fFormLayout.getComponent(error.getProperty());
if (component != null) {
if (error.isError()) {
component.setBackground(fErrorColor);
} else {
component.setBackground(Color.white);
}
}
}
setFocusToFirstError(errorList);
}
}
private void setFocusToFirstError(ErrorList errorList) {
if (errorList.hasErrors()) {
for (String field : new String[]{PERSON_FIRST_NAME, PERSON_LAST_NAME, PERSON_UNIVERSITY_ID}) {
if (errorList.containsError(field)) {
ULCComponent component = fFormLayout.getComponent(field);
if (component != null) {
component.requestFocus();
break;
}
}
}
}
}
}
Now, what does it take to add undo/redo to this example? As mentioned before, the abstract base class for the presentation model already contains generic undo/redo support. All we have to do is offering undo or redo in the user interface. I simply had to add two additional buttons for that, which call undo resp. redo on the presentation model. In addition, the view has to enable or disable the undo/redo buttons if undo/redo is possible or not. The abstract presentation model triggers this event conveniently. The extensions to the presentation model are minimal. It has to reset undo/redo when loading or saving the business object and it sets the focus in the view to the component which was affected by undo/redo.
How does the presentation model fit into an application which needs to render live data. Actually, the presentation model can also handle this scenario quite nicely. There is only one issue to consider. The data feed can be considered as yet another model which the presentation model can subscribe to. Thereby the presentation model is notified about any relevant model changes. However, these model events most likely occur outside of the UI event thread (e.g. posted by some server) and therefore they cannot be processed synchronously by the presentation model which runs in the UI event thread. The solution is quite simple. The presentation model stores these events in a queue which is processed prior to the next event that occurs in the event thread, i.e. the next event that is going to be processed synchronously. While processing the asynchronous model events the undo/redo recording has to be temporarily suspended since these events are not created by the user and therefore undo/redo is pointless.
The presentation model framework is available Presentation Model Framework. It solves many design issues in rich user interfaces and also helps developers to focus on implementing cool and ergonomic user interfaces rather than dealing with design and infrastructure issues. The framework is also independent of the user interface component library. The only exception are the table and tree model adapter classes which are specific to the ULC component library. It should be pretty simple to replace them with an implementation for the user interface component library of your own liking. Also included in the download are a number of examples which demonstrate how to use the presentation model framework. These examples were implemented with the ULC component library. In order to compile and run them you also need to download the ULC component library. You can get a free evaluation license for ULC here. Additionally, the examples need some infrastructure code (e.g. binding, form layout and validation support) which comes with the download. This infrastructure code has been extracted from a larger project and stripped down to minimize dependencies. Hence, they do not really serve as an example.
In the last chapter we will have a look at additional infrastructure which even more simplifies implementing rich user interfaces.
Part 1: MVC and the Brave New World of RIA
Part 2: The World Needs More Models
Part 3: A Simple View on Complex Stuff
Part 4: Hierarchies
Part 5: Presentation Model Framework
Part 6: What’s Needed Besides the Presentation Model
1 Comment | 
AJAX, GWT, General, Java, Java RIA, Jazoon, Rich Internet Applications | 
Permalink
Posted by Mike
