[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [e4-dev] Toolkit model
|
Hi Hallvard,
Nice to peak with you again after the last pizza (private joke ;-) ).
I just want to give some news about wazaabi 2.0 and also comment your email.
First of all, congratulations for your project, it looks clear and
efficient.
Regarding wazaabi 2.0, I did not add new widgets recently because I
strongly believe that a binding model is requiered before !
Databinding is really hard to model because it mixes workflow and
dataflow, and since we choosed to declare our UIs, it is a bridge
between declarative parts and runtime instances.
I finally choosen to use a workflow metamodel, but for most of the cases
(80 % 90 % ???) the developer (or designer) will not deal with it. I
will provide an annotation mechanism for the widget metamodel and an API
for developers who want to use it directly in the code.
My opinion about recurrent databinding pattern's (form binding,
master/slave, ...) is that we should be able to provide a CSS like
mechanism for it.
For instance, a very simple rule like "each time you loose the focus of
a text field, you copy the field value (text attribute) somewhere in our
target" could be a default behaviour.
Of course, if the dev. wants to change something like replacing the
lostFocus by another event, he will be able to.
We could also imagine that a given field attribute (let's say the
'name') will define more explicitely our target.
In this last case, the designer wont need to write any annotation or
source code except filling the 'name' attribute with the right value.
We should be able to override the default behavior in many places, from
the engine (global) untill the field itself (local), and may be all the
fields of our form.
Regarding the source and target path definitions, they will be applied
to whatever will be provided at runtime. For instance, if we define
'firstName' as target path, at runtime we could provide an instance of
'Person' or 'Employee' or whatever we want, the same for the U part
(source in this example).
Finally, by building a workflow model using annotation or API will allow
us to apply it to other parts than pure databinding (property changes,
actions, wizard flow, etc...)
My comments regarding your email are below
Hope it will help,
Best Regards,
Olivier
Hallvard Trætteberg a écrit :
Hi,
As mentioned in a previous (and lengthy) posting, I have been
experimenting with an EMF Toolkit model and SWT renderer (henceforth
called "builder"). This work is similar to Wazaabi, and will hopefully
allow us to discus various modelling and design issues.
The code is part of the diamodl UI modelling project located at
sourceforge, and can be found at
https://diamodl.svn.sourceforge.net/svnroot/diamodl under /tm/trunk
There are three eclipse projects:
- no.hal.tm, the model and generated source
- no.hal.tm.builder, the builder used for creating the UI, with some
tests
- no.hal.tm.ui, the Toolkit model view that renders the model in the
active editor
Some reflections on the model and implementation:
- Generic and specific models: I've separate models for the generic
elements and the SWT specific ones, the latter depending on and
extending the former. This split has worked well. I started with
mostly everything in the SWT model, and moved elements into the
generic one, when they seemed/became generic enough.
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).
- 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 ?
- Builder implementation: I've tried to make a generic Builder design,
but most of the code is specific to SwtBuilder. I think it will be
easier to make a good generic design after I've tried to implement
another Builder (e.g. SwingBuilder).
- Annotations: I've used annotations to help the Builder
implementation. The idea is that each Builder implementation is
allowed to add annotations to the model. It is currently used to
declare how classes, references and attributes map to SWT classes,
properties and fields. This approach makes it easier to add new model
elements, without requiring changes to the specific Builders.
- Dynamic EClasses: Some EClasses in the genmodels are dynamic, to
avoid generating more code than necessary. E.g. SWT-specific layouts,
that follow the mapping strategy supported by the annotations, may be
added without (re)generating code (only the package and factory must
be regenerated).
- 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.
I bet there are other issues, and others will arise when/if I try to
model viewers and data providers. I hope we can discuss these issues
and agree on what a UI model should look like and how supporting
tools, like builders and views should look like.
Hallvard
_______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev
