Skip to main content

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

Hi Hallvard and all,

Thanks for the note.  I'm starting my holidays and won't be back until January 5th.  I will endeavour to get caught up then, provided I don't cheat and look at work email in the interim (like I'm doing now!).

Best holiday wishes to everyone,

Hallvard Trætteberg <hal@xxxxxxxxxxx>
Sent by: e4-dev-bounces@xxxxxxxxxxx

12/18/2008 04:01 AM

Please respond to
E4 Project developer mailing list <e4-dev@xxxxxxxxxxx>

E4 Project developer mailing list <e4-dev@xxxxxxxxxxx>
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
- 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.


e4-dev mailing list

Back to the top