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

[yves.yang@xxxxxxxxxxx]

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
>