|[eclipse-incubator-e4-dev] Declarative UI|
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 whatThe 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 vocabularyThe 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 representationThe 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 formatThis 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: stylingBy 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.
Back to the top