Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipse-incubator-e4-dev] EMF based dynamic declarative UI

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





Back to the top