[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Hi all,
In general I'm positive to combining technologies, if they can add value
to each other. But before doing that, we got to understand how they fit
(or don't) together. And in this case, I think we need to look at the
essential characteristics that are important. Let me try, and then I'll
comment on Yves description and vision below.
We all seem to agree that we need declarative UI, which in this context
means an explicit representation of the UI that can be edited, stored
and turned into a real UI. There are at least three important aspects
that can make technologies differ and that we must be aware of (BTW,
this is a short version of an email I sent to the list 22/8-2008):
(Yves, please correct me if I'm wrong about XWT, in the description below).
The language (models of what):
The representation can be more or less specific to a particular toolkit
(meaning that idiosyncrasies of the toolkit's API are visible). Abstract
formats usually give less control, and some support toolkit-specific
extensions to give extra control. Some toolkit-specific formats are
(slightly) procedural, by depending on the toolkit-specific process of
constructing the UI. E.g. XSWT included a special style attribute to
handle SWT's style constructor argument, and tags that essentially
encode general method calls. I think XAML has support for this through.
XWT is SWT-specific, but I believe XAML is not (as it's a general
serialization format for object graphs). I believe XWT inherits supports
for a procedural style from XAML. TM is independent of toolkit (but not
particularly abstract), but supports toolkit-specific extensions.
Liveness of the representation:
All representations can be loaded from resource and rendered to create a
running UI. If the representation is live you may change the in-memory
representation and see the effect in the running UI. Hence, the
representation can be considered an alternative API (for some or all
purposes). You needn't use this feature, though, so you can still just
render and throw the representation away, if you want.
XWT is not live (although I believe it could be, since many XML DOMs are
observable), TM is.
In-memory representation:
The in-memory representation matters for tools that create the UI
representation and for application that operate on a live model, but is
of no concern in a render-only mode of usage. XML has many DOMs, one of
which is EMF-based, and although many support schema-based validation,
you can generally construct invalid models. EMF has a static and a
reflective API, and both are type-safe.
XWT is based on XML, so would use an XML DOM. TM is EMF-based. The
benefit of each depends on the application that manages the in-memory
representation.
yves (yingmin) yang wrote:
From my point of view, declarative UI of e4 should be capable do everything
with existing frameworks in declarative way. XWT and TM address this issues
with different technology: one is XAML and another is EMF. XWT is designed
to map every programming class without re-implement them. TM needs to
develop the renderer for each.
Not completely correct. TM (like XWT) utilizes reflection, and the
default renderer covers the typical conventions (Java-beans, public
fields, etc.). But you are correct that XWT is more flexible (that's
what XAML was designed for).
As I said, XWT's direct users are mainly SWT developers. TM are EMF
developers.
Not correct. If used in a render-only mode ala XWT, EMF is hidden in the
same way XML is hidden by XWT. You just load a resource and render,
without looking into the serialization format. Proper tooling, like a
WYSIWYG editor or a tree-based editor with preview, will also hide EMF.
But you are correct that if you want to use more advanced TM features,
like liveness, you will need some EMF knowledge.
> So the architecture I image should be:
>
---------
| TM |
---------
|
V
-------------------------------------
| XWT |
-------------------------------------
If this means that you want to translate TM files to XWT, you of course
can. But you would gain nothing, since you could just as well render TM.
The only advantage I see is if you want to process XML further, e.g.
using XSLT instead of using a model-based transformation.
If this is the runtime architecture, it currently won't work, since
liveness isn't supported by XWT. If XWT did provide liveness, it could
be done, in case TM would have to be rewritten to operate on an XML DOM
instead of SWT.
I'll be willing to do that, but Yves would have to make XWT live for it
to make sense. Then we would get the best of both worlds! (BTW, it would
be preferable to use an EMF-based XML DOM, which I think Yves is working
on?).
Hallvard
