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

[Olivier Moises <omoises@xxxxxxxxxx>]

Hallvard;

Sorry if I was not clear enough :
Tell me if I undernstand well : you propose to parse the SWT toolkit, 
and using java reflection, to create, on the fly, a metamodel.
And since every public properties, methods and events will be in the 
metamodel, the "runtime engine" will run easily.
I think it is a really good idea.

Unfortunately, not applicable in the current project, because :

* There is 2 metamodels, an abstract one is required because to rule 
future extensions or replacement of the SWT concrete one,
* the SWT meta model is not a 100 % mapping of SWT toolkit -- for 
instance, colors, fonts are objects, could be share among several 
components and of course color changes are reflected to their containers..


Olivier



Hallvard Trætteberg a écrit :
> Olivier,
>
> I think we are confusing meta-model and models.
>
> Again: If you use EMF, rather than XML and reflection, there must be a 
> complete _metamodel_ corresponding to the toolkit's API, so that all 
> widgets and properties in the toolkit may be referred to in the GUI 
> _model_. Hence, creating the _metamodel_ is a huge task. Therefore I 
> asked whether you have considered generating the _metamodel_ for SWT 
> from the SWT API (class meta info), to avoid having to build the 
> _metamodel_ by hand.
>
> Hallvard
>
> > > 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
> >
> >
> > _______________________________________________
> > eclipse-incubator-e4-dev mailing list
> > eclipse-incubator-e4-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
> _______________________________________________
> eclipse-incubator-e4-dev mailing list
> eclipse-incubator-e4-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev