Sorry, too quick to click on the button "send": Can you use it on Mars or Moon?
yves >> 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 > _______________________________________________ e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev
