Re: [e4-dev] TM and XWT

[yves.yang@xxxxxxxxxxx]

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 <yves.yang@xxxxxxxxxxx>
>
>> > yves.yang@xxxxxxxxxxx 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
>> > e4-dev@xxxxxxxxxxx
>> > https://dev.eclipse.org/mailman/listinfo/e4-dev
>> >
>>
>>
>> _______________________________________________
>> e4-dev mailing list
>> e4-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/e4-dev
>>
> _______________________________________________
> e4-dev mailing list
> e4-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/e4-dev
>