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 > [email protected] > https://dev.eclipse.org/mailman/listinfo/e4-dev > _______________________________________________ e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev
