RE: [e4-dev] Declarative UI

["Yves YANG" <yves.yang@xxxxxxxxxxx>]

Hi Hallvard,

>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.

What I presented is XWT. It uses the same concept as XSWT: SWT 1:1 mapping.
But it is really modeling mapping between XML and SWT.  

Best regards
Yves YANG
Soyatec - Eclipse OutSourcing & XAML for java
http://www.soyatec.com
Tel: +33 1 60 13 06 67
Mobile: +33 6 20 74 39 45
Fax: +33 9 58 07 06 67

-----Original Message-----
From: e4-dev-bounces@xxxxxxxxxxx [mailto:e4-dev-bounces@xxxxxxxxxxx] On
Behalf Of Hallvard Trætteberg
Sent: Thursday, December 18, 2008 10:01 AM
To: E4 Project developer mailing list
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