The next generation UI

Wazaabi provides a complete a complete model support for describing UI in SWT, SWING and JSF, but can be extended to other UI technologies.

A simple example: the Text Edit part overview

In this section we take the SWT Text Widget and we will see, from the model, how the edit part will trigger the SWT widget, and in other way, how the SWT event will arrive on the model side.

The core and still the core

Wazaabi is designed in order to extract common behaviour, independently of the target UI. For each target UI, Wazaabi provides a complete implementation of the core, with its own specificities. The Engines are designed in such a way, with a clear separation of the core Edit parts, by the way connected to the core model, and the target UI edit parts, connected to the target UI implementation model. 
In this Figure, the reader can see the quasi identical hierarchy between the Model and the engine for the TextComponent.

As the reader can see the AbstractTextComponent in the core model represents the common behaviour for all text widget in all UI technology. The SWT model exposes first an interface Text which extends the AbstractTextComponent. Finally the TextImpl is the last class in the hierarchy. In order to make the drawing easier we have intentionally forget a set of classes between TewtImpl and the first parent of AbstractTextComponent.

In the Engine part, we can see the same kind of hierarchy with the AbstractComponentEditPart and the TextEditPart.  Finally a WidgetView is attached Abstract Edit part. This SWT implementation of the view represents the SWT component. Notice that the real SWT text component is an attribute of the SWTWidgetView.

It is always a question of adapting the model

The Wazaabi EditPart are the controller between the model the UI element. As we have to listen to model change, it is normal that the Edit part are registered as adapter of the model. 
The activate() method of the AbstractEditPart registers the edit part as adapter:

 
/**
* Attaches Adapters wherever required in model parts.
*/
protected void hookModel() {

  Assert.isTrue(getModel() instanceof org.wazaabi.model.core.widgets.Widget);
		((org.wazaabi.model.core.widgets.Widget) getModel()).eAdapters().add(this);
  hookModelEAnnotations();
}

In such way all modification of the model will be fired on the adapter.

Where are the factories?

The main factory which associates a TextImpl model with a TextEditPartImpl is the WazaabiEditPartFacory.
The WidgetView is created by the WidgetViewFactory contained by the AbsractEditPart, and is implemented by the SWTWidgetFactory. This factory provides a basic implementation but can be replaces by a more clever one, looking for edit part into a repository or in a registry.

 

The helpers, the final link

In order to separate the whole logic associated to a target UI from the Edit part, Wazaabi proposes the notion of helpers. Those objects implement the inheritance by delegation pattern.
For instance, concerning the Text widget, the helpers are responsible for:

• Registering a modify listener and getting back the modify event to the model.
• SWT data such as the style and the Edit Policies

 

The hierarchy of the Helper defines the different roles played by each object. For instance, the ScrollableEditPartHelper will only be notify by the SET event of the Horizontal or vertical scroll bar, while the SWTControlEditPartHelper will be notified by the SET event on the Border property. In a general way, Wazaabi uses the inheritance hierarchy for defining the role hierarchy as we will see in the next section.

From the model to the SWT component

Well, it is time to see how a setText("Olivier rules"); will be reflected on the SWT Text component and by the way, looking forward the complete notification chain.

Let's start our example:
1. setText("Olivier rules"); on the TextImpl
2. As the Edit part is an adapter of the model, the notifyChange event will arrive on the TextEditPartImpl. The Edit part inheritance hierarchy defines the role hierarchy, that is why the change event will arrive in the AbstractTextEditPart:

 
public void notifyChanged(Notification notification) {
switch (notification.getFeatureID(org.wazaabi.model.core.widgets.AbstractTextComponent.class)) {
	case org.wazaabi.model.core.widgets.WidgetsPackage.ABSTRACT_TEXT_COMPONENT__TEXT:
		switch (notification.getEventType()) {
		case Notification.SET:
			refreshWidgetViewText();
			break;
		}
		break;
	default:
		super.notifyChanged(notification);
	}
}

3. The refreshWidgetViewText() method will set the text and asking for component re-validation

public void refreshWidgetViewText() {
    String candidate = getModelText().getText();
    String existing = ((AbstractTextComponentView) getWidgetView()).getText();
    if (candidate == null && existing == null)
        return;
    if ((candidate == null && existing != null)|| (candidate != null && !candidate.equals(existing))) {

        ((AbstractTextComponentView) getWidgetView()).setText(candidate);
        getWidgetView().invalidate();
        getWidgetView().getParent().invalidate();
        getWidgetView().getParent().validate();
        getWidgetView().fireWidgetViewRepainted();
        }
    }

4. That's all !

In order to highlight the role hierarchy of the edit part the Figure below shows a clear view of the Edit part hierarchy.