[eclipse-incubator-e4-dev] Declarative UI
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
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.