> 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 >> >> [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
