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 ?

Have you an implementation of JSF in EMF? Thru my knowledge on your
project, you have used EMF for UI modeling and not for final runtime. This
is why you are interested in PMF project.

Best regards
Yves YANG
> 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