Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [e4-dev] Declarative UI

Kevin and others,

Remy has reminded me that there's been no recent discussion on declarative UI. I know there was an intention for people to get together at ESE and discuss the topic. I guess I was hoping for some kind of output from that.

Yes, there were some discussions at ESE about declarative UI :-) In the E4 symposium there was one "session" devoted to the topic, and I think we managed to identify important issues and considerations. Although there have been several postings afterwards, I don't think I've seen a summary. So here's my take.

There were three (?) presentations at the symposium. One general (by me) and two, by Olivier Moises and Yves Yang, presenting specific implementations of declarative UI.

In my presentation I tried to classify approaches based on how close they were to a toolkit (e.g. SWT) or alternatively, to what extent they defined a domain specific model, that eventually had to be mapped to a toolkit (whether by coding Java or utilizing tranformations). In addition, two important characteristics were identified: having an explicit schema/meta-model (oops, I said meta Ed) and being "live". It is an advantage to have a schema/meta-model, as it makes reasoning and tooling easier, but it gives some overhead and "closes" the domain. Being "live" means that changes to the model is reflected in the UI, and to the extend possible, vice versa. I.e. the model may be used as the "API" instead of the toolkit itself.

XSWT is almost the closest you can get to SWT while still feeling declarative. It uses reflection instead of a schema and is not live. XAML (Microsoft and implemented by Yves Yang) is more abstract, as it may be mapped to different toolkits, but still is adapted to the target toolkit. I'm not sure if it has a schema or not, I thought it did, but I also believe it may be somewhat adapted to the toolkit. It is not live. Wasabi, by Olivier Moises, has approximately the same abstraction level as XAML, and is split in one generic and one toolkit specific model. However, Wasabi is based on an EMF (meta-)model and is live.

In the discussion, many were against having a model at all: "SWT is already a good abstraction of the toolkit, why invent another one?". In addition, it adds weight, both in the platform and the runtime (code and data). There are, however, important advantages: - The web has shown how useful it is to split the model (HTML) and the renderer (browser engine). It is easier to author and share explicit UI representations, rather than code. - A slightly abstracted model is easier to map to different platforms. This is due to both the model and renderer split, and to the slightly higher level of abstraction. - Model objects, like EMF's EObjects, are easier to manipulate than toolkit-specific objects. E.g. they support change events and reflection, so it is easier to build generic tools around them. - Styling will be easier, since there is an explicit model to reflect on, and the widget creation process is easier to control. It should be possible to use styling both to fill in defaults in the model itself and to give (toolkit specific) hints to the rendering process.

We didn't conclude much, but the discussion continued throughout ESE. I spoke a lot with Tom and Olivier and got a chance to see Olivier's Wasabi in action. I was very neat!

In general, I favor an explicit meta-model and I prefer using EMF instead of XML. The implementation should support liveness. Based on this, Wasabi seems perfect. XAML (and its friends) are XML-based and not live (although I believe it could be, since there is a DOM).

However, I'm not sure if Wasabi is a good starting point, as there is more to it than providing a live model. Since the model can be considered an API, we should carefully consider its structure and content. In addition, how to use and extend the renderer, to support additional widgets and toolkits is also important. To better understand these issues, I have started a simple implementation myself (called TM for toolkit model, and no, it is not trademarked), which I will make available fairly soon (before Christmas).

Personally, I would like us to say yes to an EMF-based model, and start discussing and comparing different ways to model the UI, e.g. based on Wasabi and my own experimental toolkit model.


Back to the top