Re: [eclipse-incubator-e4-dev] EMF based dynamic declarative UI

[Olivier Moises <omoises@xxxxxxxxxx>]

Hallvard,

Hallvard Trætteberg a écrit :
> Olivier,
>
> Olivier Moises wrote:
> > Finally, I found that EMF brings much more advantages than XML.
>
> I agree, but there is still one important disadvantage: You must model 
> the complete domain, i.e. GUI API, which is usually fairly large. One 
> possibility is to allow a generic Widget concept, with the name as an 
> attribute, and generic Property (name and value) objects attached to 
> it, and use a factory/renderer that finds the specific class and 
> properties. So, if the metamodel lacks a specific widget, you use the 
> generic one instead.
Using the toolkit does not require you to model the complete domain in 
one huge emf model. It respects the "GUI composite pattern" allowing you 
to split up you GUI into several parts.
The runtime engine make it possible to have as many viewers as you want.
A viewer (which link the model to the GUI) is embedded in a SWT 
composite and could be placed whereever you want (you need a composite 
parent to place it).  Viewers are custom GUI components.
You could also have more than on viewers in the same Eclipse View or 
Editor.
This is extremlly usefull when you want to mix components covered by the 
framework and components which are not for example.


> > Stylesheets
> > I am not sure to need more than that like cascading effects,
> > this question is still open.
>
> It would be interesting to make an EMF stylesheet mechanism, that is 
> used for filling in defaults. So instead of styling the final GUI, you 
> style the model and then build the GUI. The model could include some 
> generic style-oriented attributes, like class, style and role, that 
> may be used in selectors.
Good idea, but, for me, it sounds more like a m2m transformation rather 
than Runtime Engine purpose.
> > Generating the model from a java API :
> > Do you mean, generating the EMF GUI from an existing application 
> > (domain objects ...).
>
> No, I meant build the metamodel from the toolkit's API, so you get 
> more complete coverage of the features in the underlying toolkit.
Actually, there is a abstract core meta model and a SWT concrete one.
In the future I plan to add SWING metamodel, eRCP... if possible ;-)
Generating the whole SWT metamodel could be possible but you will need 
to link for instance SWT Button to Abstract Button....
Generating the metamodel is the first step, the second one is to write 
Java code to bind metamodel classes, properties ... to the Runtime Engine.
But during both steps the generation could be a good idea to win time.
> Hallvard
> _______________________________________________
> eclipse-incubator-e4-dev mailing list
> eclipse-incubator-e4-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev