[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [e4-dev] Important e4 call reminder
|
Tom Schindl wrote:
Because I'm unsure whether I can attend the call tomorrow I'm sending
out this via mail.
Inspired by Tom, I would like to elaborate on my interests, which is UI
development based on modeling technologies.
I see the current e4 as a very interesting prototype, with many
interesting aspects and techniques. At some point (now?) we should try
to be explicit about what we've learned, what we believe in and converge
on what should be the future direction. E.g. if our experience shows
that EMF is a solid foundation, I think we should discuss if and how to
utilize it more broadly, rather than for some parts here and there.
Many issues are difficult to discuss, because we don't have the
necessary knowledge (or time to gain it) of each others work. E.g. I
think the renderers for TM and the modeled workbench essentially try to
solve the same problem, but we haven't had time to learn from each other.
Although we have demos that showcase what various components provide,
I'm not sure what they actually prove. E.g. TM and XWT seem very similar
(at the webinar yesterday someone asked why e4 includes both) and the
demo shows that XWT is more mature. But the interesting thing is the
difference, e.g. how EMF and XML compares.
What have I learned from TM (so far):
- Using EMF works well and saves time, both for modeling and
implementing tools. I'm confident EMF is a good choice.
- The rendering mechanism wasn't that hard to make, and the use of model
annotations to drive the renderer shows potential. I think I have
managed to make a good separation between the general rendering strategy
and the widget-specific parts.
- Scalability of the renderer is an issue, both resources (time and
memory) as model instances become large, and complexity, as the model grows.
- Although I have recently (after 0.9) added a simple styling model, it
is in general difficult to handle the process of (in)validating (notice
an important change) and (re)styling (which parts should be refreshed)
cleanly and efficiently.
- I've explored several ways of making TM extensible, with different
levels of power and complexity.
- Scripting provides great flexibility in two ways: 1) the underlying
Java-objects can be given extra methods when used as Javascript objects,
and 2) with scripts as part of the model, a lot more of the UI can be
customized with simple means.
- Without better editor and debugging support, using Javascript is a lot
of trial and error.
- There's a big extra benefit when using EMF for the application's data
model, because it simplifies integrating with the UI and the scripting
support can be used for the application data.
In general, I'm sure I could learn a lot from the experience with the
modeled workbench design and implementation.
Things I commit my personal time to work to:
--------------------------------------------
- more complete coverage of widgets, particularly trees and tables
- integrate 2d graphics (I have an SWT-specific version of Piccolo
running, and a renderer for basic scene-graph nodes like rectangles,
polylines, text and image)
- implement a more complete demo, e.g. the contacts demo
- explore how CDO can be used for managing shared UIs
Things I would work on if I have time (money isn't an issue, but I would
like the work to lead to academic publications, which is "money" in my
"business"):
--------------------------------------------------
- integration with the modeled workbench, and learning from their experience
- better support for editing and debugging Javascript
- an Ajax renderer
I hope we can find time to discuss these issues, in the mailing
list/wiki/bugzilla and at ESE.
Hallvard