Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [e4-dev] how to contribute to toolkit model ?

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 <yves.yang@xxxxxxxxxxx>
>
>> 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 <yves.yang@xxxxxxxxxxx>
>> >
>> >> 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
>> >> > 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
>> >
>>
>>
>> _______________________________________________
>> 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
>




Back to the top