[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [e4-dev] Toolkit model
|
Olivier,
Olivier Moïses wrote:
Nice to peak with you again after the last pizza (private joke ;-) ).
:-) It was nice to speak and eat with you at ESE. Very inspiring!
Regarding wazaabi 2.0, I did not add new widgets recently because I
strongly believe that a binding model is requiered before!
Binding is important, I agree. Modeling it needn't be that difficult, if all the
objects, including domain and toolkit, are Ecore objects.
I may have mentioned my dialog modeling language diamodl, which is my line of
research. Besides activation logic, it models dataflow to/from the model and UI
components, i.e. databinding. There are three main concepts: variables for
holding data, computations for transforming data, and widgets for referencing
the toolkit objects. The model is translated to EClasses (which is combined with
the domain model to a large Ecore model), and the runtime consists mainly of
instances of these (and domain data), with references to the toolkit model
objects and databinding for moving data inside the UI and to/from the toolkit.
So, in practice databinding is modeled as a link between a structural feature of
one Ecore instance to a structural feature of another.
How do you validate the move from SWT specific to generic one ? The
policy I apply (but I am definitely not sure) is "each time a piece of
behaviour appears in SWT and SWING, then move it into Abstract/Generic
metamodel).
Yes, something similar.
- Package structure: Like wazaabi, I've split the model into widgest,
layouts and styles packages. The disadvantage is that the generated
package and factory classes will have the same names (although in
different Java packages).
Couldn't you add an annotation for the generated classe name?
The classes are generated from genmodels, so (re)naming must be handled there.
In practice, the name collision is not a problem, as specific Builder classes
mainly use classes generated from one model.
- Events: Events are modelled as transient attributes that invalidate
the reference/attribute corresponding to the input value. This means
that event info. is available for the application. In my experience
this is needed, e.g. to detect whether a change to a Text widget
resulted from a keystroke or a programmatic change.
Why only transient attributes?? for instance, the selection of a
checkbox could/should be persisted. Independently, the selection change
will trigger an adapter.
The event itself is transient, while the affected property is not. E.g. a toggle
button (and a checkbox) has a transient selectionEvent attribute and a
persistent selection attribute, while a push button only has the transient
selectionEvent attribute.
Hallvard
