|Re: [eclipse-incubator-e4-dev] Fw: Declarative UI roundup?|
Kevin,>My concern is that inevitably when you go to an abstraction, you inherently lose some fidelity.
Not sure if you split up you metamodels. :One could hold the common behaciour of widgets regardless where are they coming from (swt, swing, ...), a second one, inheriting from the first one could add specific SWT behaviour.
In the second you could achieve 1;1 swt mapping.> <naiveQuestion>Isn't this solved to a great degree through the use of databinding?</naiveQuestion> Databinding is a bridge between two worlds : the structural declaration of UI and the runtime one. EMF could give some ways to solve it. For instance, given a Tree, we need to bind it with a Input, ContentProvider and a LabelProvider in a Viewer class. Let's say that our Viewer has two references : a ContentProviser EClass and a LabelProvier EClass.
At runtime, we need at least have a running instance of the tree and of course a valid input which is often a domain object (or a set of). In most of the cases, ContentProviders is a simple inheritance of the JFace one (no specific constructors). Then is this cases, our Viewer EClass could have a reference to a Concrete ContentProvider EClass which has a string propertie containing the fully qualified class name (at runtime we instanciate this class using reflexion). But in some cases, we need specific constructors for instance the ContentProvider. In this cases, at design time we could write our ContentProvider inheriting from AbstractContentProvider EClass. At runtime, we instanciate it and bind it to the existing instance of Viewer EClass.
In both cases, at no time I ever dealed with specific SWT behaviour. Olivier Kevin McGuire a écrit :
Back to the top