[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [e4-dev] Declarative UI
|
[...]
>
> I discussed this with Tom at ESE, and I agree that UFace technically
> could have this role. UFace contains a lot of relevant and important
> code for implementing the rendering logic, i.e. controlling the
> life-cycle of toolkit objects and managing binding. However, consider
> the state at runtime if UFace as a whole is used. You will have
> EObject <-binding-> UBean <-binding-> SWT widget, instead of the simpler
> EObject <-binding-> SWT widget.
Your observation is completely right and it looks like you hijacked my
dreams. Yesterday, before going to bed, I thought about this and about
how I could define UFaceKit using Ecore.
Currently all this is floating around in my head but I have no final
idea of how I could make the UFaceKit way of doing could be programmed
in EMF.
Here are some of the problems I haven't solved (yet):
- SWT-Widgets require a parent at creation time where as EMF-Object are
created with a no-arg constructor
- How could I satisfy all the needs of constrained devices that don't
want to have a live model and to which we need to port EMF; my main
target is GWT => I already ported it once but this is a huge task...
What I still say---I discussed this yesterday with Kevin on IRC---is
that a 1:1 declarative UI definition works as long as you don't mix in
CSS. But at this very moment 1:1 fails because one might be needed to
create certain effects to modify the Widget-DOM, e.g., nest a control in
an artificial composite to show a shadow border.
Still we all agree that the widget hierarchy from the outside should not
change just because I create a shadow-border, for the user.
You could argue that SWT should take care of all these features we
wished were there, but IMHO this is not the task of SWT; it should give
us a clean and concise abstraction of the native widgets no more nor
less. By pushing features like shadow border down to SWT we only make
SWT more bloated and this not what any of us want.
So what we need is a higher level of abstraction as thin and as concise
as possible. If UFaceKit could give first ideas to make this possible, I
would more than welcome all of you to step in and help us to get there.
We are open for every suggestion and contributer /committer who helps us
to bring this project one step forward and make it usable to all of us.
I might have to mention that UBean-API and all things built on it are
inspired by EMF but exposing less meta-data then EMF does, e.g., we
don't care a but operations...
A UBean simply provides the following things:
- Reflective Attribute Interface by copying EMF-eSet/eGet
- Generic Event-System by copying EMF's notifications
- Access to Feature-Types and Features (EMF-ePackage)
I don't know if by restricting ourselves to those features (e.g., all
those specialized EMF-Lists, EOperations, ...) we could extract a new
smaller EMF-Module we could use....
So here's my (revised) design of how the current work in UFaceKit can be
exploited to use EMF (as it is now without any changes to extract
slimmer super-classes/interfaces)
UFaceKit-Interfaces
^
|
---------------------------------------
| |
ConstraintedDevice AbstractUFaceKitEcore
^ ^
| |
---------------------- -----------------------------
| | | | | |
Android eSWT GWT SWTEcore SwingEcore QTEcore
Currently UFaceKit has implementation for SWT, Swing and QT and the only
missing piece is to create the AbstractUFaceKitEcore and the let the
current concrete implementation inherit from them. Once we could
Parallel-IP approval I'll check in the current sources and switch the
design (yeah I just made this decision :-)
Tom
--
B e s t S o l u t i o n . a t EDV Systemhaus GmbH
------------------------------------------------------------------------
tom schindl leiter softwareentwicklung/CSO
------------------------------------------------------------------------
eduard-bodem-gasse 8/3 A-6020 innsbruck phone ++43 512 935834
