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 > > [email protected] 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 >>> [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
