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,

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





Back to the top