Re: [e4-dev] Important e4 call reminder

[Hallvard Trætteberg <hal@xxxxxxxxxxx>]

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