[e4-dev] Toolkit model

[Hallvard Trætteberg <hal@xxxxxxxxxxx>]

Hi,

As mentioned in a previous (and lengthy) posting, I have been experimenting with 
an EMF Toolkit model and SWT renderer (henceforth called "builder"). This work 
is similar to Wazaabi, and will hopefully allow us to discus various modelling 
and design issues.

The code is part of the diamodl UI modelling project located at sourceforge, and 
can be found at https://diamodl.svn.sourceforge.net/svnroot/diamodl under /tm/trunk

There are three eclipse projects:
- no.hal.tm, the model and generated source
- no.hal.tm.builder, the builder used for creating the UI, with some tests
- no.hal.tm.ui, the Toolkit model view that renders the model in the active editor

Some reflections on the model and implementation:
- Generic and specific models: I've separate models for the generic elements and 
the SWT specific ones, the latter depending on and extending the former. This 
split has worked well. I started with mostly everything in the SWT model, and 
moved elements into the generic one, when they seemed/became generic enough.
- Package structure: Like wazaabi, I've split the model into widgest, layouts 
and styles packages. The disadvantage is that the generated package and factory 
classes will have the same names (although in different Java packages).
- Builder implementation: I've tried to make a generic Builder design, but most 
of the code is specific to SwtBuilder. I think it will be easier to make a good 
generic design after I've tried to implement another Builder (e.g. SwingBuilder).
- Annotations: I've used annotations to help the Builder implementation. The 
idea is that each Builder implementation is allowed to add annotations to the 
model. It is currently used to declare how classes, references and attributes 
map to SWT classes, properties and fields. This approach makes it easier to add 
new model elements, without requiring changes to the specific Builders.
- Dynamic EClasses: Some EClasses in the genmodels are dynamic, to avoid 
generating more code than necessary. E.g. SWT-specific layouts, that follow the 
mapping strategy supported by the annotations, may be added without 
(re)generating code (only the package and factory must be regenerated).
- Events: Events are modelled as transient attributes that invalidate the 
reference/attribute corresponding to the input value. This means that event 
info. is available for the application. In my experience this is needed, e.g. to 
detect whether a change to a Text widget resulted from a keystroke or a 
programmatic change.

I bet there are other issues, and others will arise when/if I try to model 
viewers and data providers. I hope we can discuss these issues and agree on what 
a UI model should look like and how supporting tools, like builders and views 
should look like.

Hallvard