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.

The core model

The Wazaabi `core' model intends to define different components that a generic graphical UI can be made of along with a set of objects used for the rendering of those graphical elements (called widgets in the `core' model). In a way, this model can be viewed as a GUI meta-meta-model. All model elements of UI frameworks meta-models thus need to extend those `core' generic elements (whether it is the Swing.ecore meta-model or the ICEfacesComponents.ecore meta-model).

Most of the graphical elements in the `core' model are abstract because their definition is dependent on the platform. Other elements whose definitions are established regardless of the platform (e.g. a Column, an Image or a Stylesheet) are concrete in the `core' model. This implies that the various derived platforms will be able to instantiate a Column but this instance will be of a `core' model object.
The `core' model is divided into five distinct packages.

Package : widgets

The widgets package holds the abstract definition of all the graphical components of a UI framework such as widget, layout, style, action. Some of the main elements in this model are the followings :

• Widget is the ultimate abstract superclass. Each and every element, whether from the `core' model or another derived one, extends this class one way or another and is therefore a Widget ;
• AbstractComponent extends Widgets and represents any graphical component of the UI. Some Widgets are not AbstractComponents as we will see ;
• AbstractContainer is an AbstractComponent that represents graphical elements that are meant to have children components (e.g. a Swing JPanel) ;
• AbstractButton represents any kind of graphical button. These can be simple \push" buttons (AbstractPushButton) or \toggle" buttons (AbstractToggleButton) such as the checkbox for instance (AbstractCheckbox)
• AbstractTable is one of the latest additions to the Wazaabi `core' model. That is because
  tables do not exist as such in previously integrated framework (at best, Swing and SWT organize elements with Grid layouts). The AbstractTable represents table elements as well as tree elements. The idea behind this implementation choice is that a table is basically a tree with no hierarchy. Therefore the element, modelled as an AbstractTable element, will be rendered either as a tree or as a table depending on the value of its "hierarchical" flag attribute.

Package : layouts

This package, as its name implies, is associated with the positioning of the widgets. The structure is very similar to that of SWT. Here are the main features of this package :
Layout is a concrete EModelObject which, when associated to an element of type AbstractContainer,
defines how the child components will be rendered within the said container. LayoutData on the other hand can be associated to any child AbstractComponent and specifies how that particular component has to behave inside of its parent container.

Package: Viewables

The package viewable is specific to Table elements. It holds the mechanics for populating and rendering of table elements. The basic idea is that a Table implements the Viewable interface, receives business Objects from the underlying model as an input. The Table also has both a ContentProvider and a ContentRenderer. The first will be responsible for turning this input in elementary data whereas the latter will be in charge of displaying these elementary data (labels, images,...). This implementation method was chosen above populating the table with `meaningless' TableItems, which don't have any true relation with the business objects they are meant to represent.

Package : Styles

The styles are a attempt to map the CSS behaviour on EMF. This package requires update in order to fully support the CSS-like skinning.

Package : Actions

The Actions concern all related action on button or other element requiring actions, i.e., actions performed by components. For instance, clicking on the `Submit' button of  an HTML form makes him perform the Action of submitting the content of the form. In  other words an action is a call to a method from another object.

• AbstractAction represents any action. It can be enabled or not and it has a `run method
  that takes an ActionEvent argument and executes the Action.
• ActionPerformer is an interface that is implemented by widgets such as Abstract-
  Buttons that have to perform an action.

Package : Resources

This packages manages colours, images, fonts, etc.

Why do we need models?

In Wazaabi, the UI as described (declared) as model. The engines are responsible for rendering the model as UI.