By the way, JSF is XML-based. Anyway, as I said, EMF UI may be good a solution in a specific context.
yves > Hi All, > > I would like to share my personal experience as R&D Technical leader at > Alcatel-Lucent and UI model. > > During our evaluation of technologies for modeling our UI (a complete > framework for network Application servers provisioning), after weeks of > study, we decided to move toward live EMF models and especially the open > source Wazaabi 2.0 Framework. > > The real advantage we found in live models, comparing to XML, is that all > the code of the model was already there, going further, we have developed, > in collaboration with Wazaabi, a complete model for binding business model > (data model used in Application server) to GUI model. As a result no > generation code is needed; we just re-use all the code provided by the > binding model. > > This live binding model is a real BPMN workflow engine, which is much more > powerful than a simple XSLT transformation. In addition we realized that > this model is real live M2M binding, that makes us use the binding model > in > other domain such as Call Data Record integration. > > I have to say that we generate automatic JUnit Test for testing the GUI > model, which is also a consequence of the live orientation of the model. > > Finally, we use the same GUI model in a GEF editor for modeling the GUI, > while the final GUI is JSF-based (but still live-EMF-model based). > Best regards. > > Sabri. > > PS: The web site http://www.wazaabi.org/index.php?title=Main_Page is a > basic > description of the framework, we are working in collaboration with authors > to update the documentation, architecture description, etc. which is not > inline with the Version 2.0 > > 2009/9/2 <[email protected]> > >> Hi Mingjian, >> >> XWT relies on a model defined by IMetaclass. At the low level, XWT is >> mapped to SWT/JFace by default. You can change the mapping by replacing >> the metaclass. For instance, you have a button: >> >> <Button text=""/> >> >> By default, it is mapped org.eclipse.swt.widget.Button. You can override >> it by your own Button: org.custom.Button. >> >> XML isn't humain readable than JSON. But it is good for model-to-model >> transformation. XAML tries to keep it as more readable as possible. >> >> The difference between JSON and XML is the extensibility. With JSON, you >> have a parser, which is hard to extend. With XML, it is very easy. You >> need just to add a new namespace. We use this concept to handle the CSS: >> >> <Composite xmlns="http://www.eclipse.org/xwt/presentation"; >> xmlns:x="http://www.eclipse.org/xwt"; >> xmlns:css="http://www.eclipse.org/css";> >> <Composite.layout> >> <GridLayout numColumns="3" /> >> </Composite.layout> >> >> <Label text="General" css:id="SeparatorLabel" /> >> </Composite> >> >> The CSS speficication is handled by a CSS engine. You can define your >> namspace handler. >> >> Regards >> yves >> > Hi, Yves, >> > >> > I understand your viewpoint. I hand your idea of "separation between >> > concept >> > and implementation". And your works at e4 0.9 new features are pretty >> > nice. >> > For the name of "XWT", I guess it is XML-based? However, the strong >> > binding >> > UI to XML is not very suitable. One advantage of EMF is that EMF >> defined >> > in >> > a higher level, and then the way persistence of EMF could be changed >> to >> > anything if someone like. >> > >> > For instance, (assumed) I like JSON or Google protocol buffers more >> than >> > XML. Did XWT provide this kind of implementation?(or say, is there a >> full >> > "separation between concept and implementation" for XWT?). If XWT can >> give >> > me this choice, I think it is acceptable as well:) >> > >> > >> > ps: I am not familiar with the XWT, If I am wrong, correct me:) >> > >> > best regards, >> > Jin >> > >> > >> > 2009/9/2 <[email protected]> >> > >> >> Hi Jin, >> >> >> >> 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 > _______________________________________________ e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev
