I think we should give a name for XAML + eclipse. How about XWL ? I cannot see the benefice to use EMF to manipulate XWL in runtime. But I do think it is useful to add a package to read/write XWL resource in EMF API, which can be used by all EMF tools such as TM.
Best regards Yves YANG > Hi, Yves: > > "I think you should understand why XWT cannot be on top of TM." > > > How about build XWT on top of EMF? Maybe I should see some XWT sources. > Adding a extra EMF layer may be not necessary for directly manipulating > SWT. > But this make your two team could joint your effect, And it make some > high-level EMF manipulatings possible. > > Jin > > 2009/9/3 <[email protected]> > >> > [email protected] wrote: >> >> >> >> 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". >> > >> > Both TM and XWT resources (files) are UI representations, based on EMF >> > and XAML/XML, respectively. The fact that XWT doesn't need it once it >> > has been loaded and the UI rendered doesn't change this fact. Tools >> that >> > are used for editing must have it in memory. >> > >> >> 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". >> > >> > What I think you mean is that the XWT representation doesn't exist in >> > addition to the SWT object during runtime, once the latter has been >> > built. You throw it away, and the application programmer uses the SWT >> > objects for handling events and manipulating the UI. So it's SWT that >> is >> > "live", not XWT. >> > >> Yes, it is REALLY simple. In general, we should keep simple. NetBean >> doesn't the same way. >> >> > There are three kinds of advantages of a live representation (that I >> can >> > think of at this moment): >> > - It provides more flexibility, e.g. even if SWT doesn't support >> > changing style bits, XWT could allow it and under the covers >> > re-instantiate the SWT object >> >> I guess TM and XWT uses the name concept. >> >> > - It provides a higher abstract level or otherwise mentally cleaner or >> > simpler model, e.g. a simpler class hierarchy, uniform styling model, >> > etc. This is not that relevant for XWT, since it is SWT-oriented by >> > design. >> >> We should split developers in two groups: UI Element provider and UI >> Consumer. >> >> What you said is true for UI Element Provider. But for the UI Consumer, >> XWT does privide also abstract level. For me, the most important is the >> separation. >> >> I think you should understand why XWT cannot be on top of TM. >> >> Best regards >> Yves YANG >> > - The underlying representation (EMF or XML) may better support >> generic >> > operations like copying hierarchies, visiting nodes, querrying, >> > observing, persisting, transformations etc. >> > >> > 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 >> > _______________________________________________ > 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
