Re: [e4-dev] TM and XWT

[yves.yang@xxxxxxxxxxx]

Hi Hallvard,

What's your definition of representation? I guess it is EMF object which
defines UI. With EMF, you have to deal this new layer. And of course, you
need to a "live model".

In XWT, this layer doesn't exist. XWT can be considered as a simple
Loader, which read XML file and create immediately SWT widget. So we don't
care of "live model" or precisely "live layer". It is always "live".

Best regards
Yves YANG
> 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
> _______________________________________________
> e4-dev mailing list
> e4-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/e4-dev
>