Re: [e4-dev] how to contribute to toolkit model ?

[yves.yang@xxxxxxxxxxx]

> I suppose you have a car, by which you can go anywhere (on land of
> course). Can you use it as a boat in ocean ?
Better question is:
  Can you use it as a boat on Mars or Moon?

yves
> Hallvard,
>
>>
>> I've worked a lot with XML-based UI representations and have looked at
>> most of the languages that exist, and I've contributed scripting and
>> editing tools to XSWT. XSWT is almost equivalent to XWT, by providing a
>> direct mapping to SWT (no abstraction). The general problems of XSWT
>> were twofold:
>> 1) By being a direct mapping to SWT, it didn't really make things
>> simpler, as you both had to understand SWT and the mapping technique
>> (which became complex to support all aspects of SWT).
>> 2) Working with XML is perhaps OK if you're editing it as a file, but
>> when you must manipulate the XML DOM in an application, e.g. for
>> changing the UI during runtime or building the XML document from some
>> other representation, it becomes cumbersome. This is partly because of
>> XML's weak, untyped structure, partly because of the complexity of the
>> mapping to SWT, which to some extent is reflected in the application's
>> code.
>
> I just remind you XAML ueses the similar concept as XSWT. But it is much
> more complet, mature and model-based (see below about its definition). It
> is designed for application description (A = application) including
> workflow. The UI is just one part of its application domains. So XSWT is
> not comparable with XWT.
>
> I suggest you to look at XAML in .Net/Siverlight. You will discovery a new
> continent as you did with EMF (I suppose).
>
>>
>> So the problem was not that there is no standard for XML-based
>> declarative UI,
>
> Yes, but there is a standard in .Net/Silverlight. Why do use the
> specification in eclipse? How long do you take to reinvent it? How much
> the risk for eclipse?
>
>> but intrinsic problems with XML and the mapping to SWT.
>>
>
> XWT has resolved it.
>
>> For me the solution was to reuse the good ideas from XSWT in an
>> EMF-based solution. I was about to take Wazaabi
>> (http://www.wazaabi.org/index.php?title=Main_Page) as the starting
>> point, but since I wanted to better understand the implementation issues
>> and instead started on TM.
>>
>> A weakness of a model-based solution seems to be that you have to model
>> all the widgets you want to use in advance, while in X(S)WT you can just
>> use the name of the widget class as a tag and you get what you want.
>> However, it's easy to use the same reflection techniques as XWT uses, to
>> generate the EMF-based model, since EMF supports dynamically creating
>> classes and instances.
>
> Please take care of the word "model-based". I make the difference between
> "model-based" and EMF-based. "model-based" UI is generic concept.
> EMF-based UI is concrete. XWT is "model-based" since it has a SWT model,
> but XSWT is not.
>
> As I said before, the weaknesses of EMF-based UI are the extensibility and
> flexibility. They are much more important.
>
>>
>> As I've argued before, an important strength of an EMF-based
>> representation is how well UI model instances can be managed by existing
>> (and future) Eclipse tools. (EMF is almost becoming a native Eclipse
>> object model, now.)
>>
> I suppose you have a car, by which you can go anywhere (on land of
> course). Can you use it as a boat in ocean ?
>
> Yves
>> Hallvard
>>
>> yves.yang@xxxxxxxxxxx wrote:
>>>
>>> A declarative UI is very important for e4 to simple UI development for
>>> enterprise SI presentation. It provides a separation between concept
>>> and
>>> implementation, and unify all UI frameworks and data frameworks
>>> (including
>>> EMF) to work together. It should be the foundation of eclipse for all
>>> UI
>>> Tools such as VE, MDA like PMF/EGF. So the standardization of
>>> declarative
>>> UI in e4 is absolutly necessary for the success of e4.
>>>
>>> Without this standard, it will be a masse. We are already in this
>>> situation in Java. There are XUL, Xform, XSWT and others, but no
>>> standard.
>>> Who dare to use it? Which tool support it?
>>>
>>> Best regards
>>> Yves YANG
>>>> EMF seem higher level technology than XML. EMF provide many advanced
>>>> tools
>>>> to solve the actual world's problem. A XML file is a data aggregation.
>>>> But,
>>>> it is simple to understand. However  parsing many XMLs or one big XML
>>>> is
>>>> not
>>>> lightweight absolutely. And so I don't much like the idea of "XML
>>>> Everywhere". But, One question is that, is it possible to make all
>>>> additional technologies as the options for e4? we don't need be forced
>>>> to
>>>> choose one specific technology?
>>>> best regards,
>>>> Jin Mingjian
>>>> _______________________________________________
>>>> 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
>>
>
>