[eclipse-incubator-e4-dev] Declarative UI

[Hallvard Trætteberg <hal@xxxxxxxxxxx>]

Hi,

I thought I'd share some reflections about using models and XML for UI 
description. There are many issues to consider and I hope to help provide some 
structure to the discussion. Since I have been working on XSWT, the 
hopefully-soon-to-be-reborn XML format for SWT, and will relate the discussion 
to it.

Topic 1: models of what

The first issue concerns what we are actually trying to describe. Most formats 
target specific toolkits or concrete models of such, including specific widget 
types, style (color, fonts, margins, padding, etc.) information, layout logic. 
Some formats, like XUL, try to be independent of a specific toolkit, but it is 
still a model of a toolkit, just not a specific one. Tom Schindl's format/model 
of the workbench describes something different, by being more 
application-oriented. It has its own vocabulary without toolkit concepts like 
button, label, list etc. In my view, models may be thought of as lying along an 
axis/dimension with application-oriented in the left end and toolkit-specific in 
the right end (the direction doesn't matter, as long as we agree). Usually there 
is a process whereby application-oriented models are mapped to toolkit-specific 
ones, but there is seldom an explicit XML-like representation of each model. 
E.g. in Tom's case, the mapping to a toolkit is implemented in the workbench 
code and there is no explicit SWT XML representation before SWT widgets are created.

When we discuss these formats, we should be clear what we model, or where along 
the axis our model lies. I think there is a need for both (toolkit- and 
application-oriented) kinds of models, and they shouldn't be mixed.

XSWT is a model of a specific toolkit (SWT), but since it is based on reflection 
may be extended to cover most API's.

Topic 2: open or closed vocabulary

The second issue is whether the vocabulary is limited by a model, schema or 
fixed implementation, or whether some discovery mechanism like reflection is used.

When targeting a specific toolkit, I believe an open vocabulary is a must, since 
 most toolkits are so big that enumerating every possibility is not worth the 
effort. When creating new application-oriented models, it is more practical to 
explicitly model the possibilities, since abstraction and simplification is 
often what you're striving for. Tom's workbench model is an example of that.

XSWT has an open vocabulary, as it does not enumerate the possible names in the 
XML, but uses reflection to resolve them.

Topic 3: underlying representation

The discussion about EMF vs. DOM concerns the underlying representation, not 
what is modeled. And as Ed notes, EMF can model DOM, and since most 
representations can handle graph structures, it is more about whether the 
representation is practical and familiar, than power.

When having several models in the same system, e.g. both application- and 
toolkit-oriented ones (or underlying data), it is a easiest to use the same 
representation for both/all. Personally I favor EMF, since I anyway use it for 
application data, and I believe (and agree with Ed) that more developers are 
familiar with it (and like it) than DOM. I don't think that the argument that 
most developers using XML and CSS know DOM is that relevant, since the 
programmers we target to a greater extent will be Eclipse and not web developers.

XSWT has its own and very simplified model for reading the XML and provides a 
simple API for getting hold of the rendered widgets. It does not provide its own 
databinding or event/notification mechanism. I think that it is possible to use 
EMF for XSWT, by implementing a Resource class that generates meta-objects 
(classes, properties, etc) and annotation for the XML mapping on the fly when 
loading the resource.

Topic 4: the physical XML format

This is related to how natural the XML feels for it's audience and of course 
depends on who the audience is: Eclipse programmers, web designers, GUI 
programmers and/or tool programmers.

XSWT tries to be as compact and close to the SWT API as possible, to be 
practical for existing SWT/UI programmers. E.g. elements (usually) map to both 
class and property names, depending on reflection and heuristics, attributes map 
to properties and attribute values are interpreted as values/objects by custom 
handlers. I've seen more generic formats similar to EMF's XMI and this usually 
leads to more (very) verbose XML. However, a generic format is often easier to 
manage for tool developers. Fortunately, EMF can handle many different physical 
formats for the same model.

Topic 5: styling

By styling I think of defaulting of usually non-functional features. One of the 
main problems with styling is that it requires a defined mapping/rendering 
model, which we lack. E.g. is styling managed by the toolkit and how (by the 
constructor of widgets, by a factory, using AOP, ...), what attributes are 
supported (standard and/or custom ones). In principle, you can style any model, 
by defining the styleable attributes and a mechanism for processing the unset 
ones. The difficulty comes when using one model M1 to style a dependent one M2, 
since you must also define how to pass styled attributes/values from the 
processing of one model (M1) to the other one (M2). E.g. you may pass 
information to an explicit mapping/transformation process M1->M2 or provide 
style information based on M1 to the processor for M2. Without explicitly 
describing this process, the style "programmer" won't know what happens.

XSWT supports style names that refer to other XSWT markup that is used to 
generate/fill objects before the explicitly specified ones. E.g. if a 'label' 
element has style 'red-label', the markup for 'red-label' is looked-up and 
processed before the rest of the 'label' element is processed. This way, 
specified values will override style values.

Hallvard