Re: [e4-dev] Declarative UI

[Kevin McGuire <Kevin_McGuire@xxxxxxxxxx>]

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,
Kevin

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>

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

Hallvard

_______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev