[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipse-incubator-e4-dev] Declarative UI, EMF vs DOM?

Hi Ed,

Thank you for your answer and your explanation. I'm newbee with EMF and I don't want have trouble with you.
I would like just know opinion people about EMF.

Regards Angelo

2008/8/21 Ed Merks <ed.merks@xxxxxxxxx>
Angelo,

Big shocker that I should respond hey? :-P



Angelo zerr wrote:
Hi,

I don't know if my title post is correct, but I would like start this topic to write something into Wiki.
I say EMF (or another thing) vs DOM because I would like purpose TK-UI to manage Decalarative UI and set pro/cons for EMF and TK-UI.
In Binding XML to Java we showed the equivalence between DOM and EMF; there's a one-to-one correspondence between the concepts.  From this perspective EMF is not a better DOM!  But we also showed how knowledge about the schema underlying a specific DOM allows one to build a better API than generic DOM.


TK-UI is Toolkit for User Interface where you can describe your UI with any XML markup (today XUL and XHTML start to be
implemented and I have intention to implement XForms) and you can mix XML markup into the same description.

<html:input type="text" id="myInput" />
<xul:textbox />

TK-UI manage UI with DOM Document like WebBrowser DOM Document (with _javascript_).

Document document = ....
HTMLElementInput input = document.getElementById('myInput');
input.setValue("bla bla bla");

I have read into this forum that EMF please a lot of people to manage Declarative UI.
And here that I have understood

User describe UI with XMI into Window.xmi like this :
It doesn't have to be XMI.  If you have a schema for how you'd like it to look, you can use that and serialize to conform with it.


<xmi:XMI xmi:version="2.0"
        xmlns:xmi="http://www.omg.org/XMI" >
  <Window>
    <Textbox value="bla bla bla" />
  </Window>
</xmi:XMI>

And it load it with ResourceSet :

URI fileURI = URI.createFileURI(new File("Window.xmi").getAbsolutePath());
Resource resource = resourceSet.getResource(fileURI, true);

Window /* EObject */ window = resource.????;
Yes, if you know it will be a Window, you can have an API with simple methods.  And you can represent numbers as numbers rather than as strings.  In other words, you can exploit the type system to know more about the structure.

Of course it will also be an EObject, so you can access it that way too, but that will be much like using DOM, though more structured and strongly typed.
Textbox textbox = window.????
window.getTextbox I would assume...

textbox.setValue("XXXXXX");

So here how I have understood the final UI API.
Is it correct?
Yep.


So with EMF UI is managed with Ecore model (EObject...) and custom java method (setValue)
and with TK-UI UI is managed with DOM Document and custom java method (setValue).
DOM generally uses more space...


Here pro/cons for EMF and DOM that I see :

EMF :

    pro:
       1. Provide a model (XSD, XMI..) to define structure of widget (Window, Textbox...)
       2. Provide a lot of tools to manage EMF.
   
    cons:
       1. New API to learn for developer (like me) who doesn't know EMF (but perhaps EMF is very knowed?).
No matter what, one needs to learn the "model" of the data being manipulated.  A generated bean-like API  is something all Java developers will understand.

     
DOM (TK-UI) :

     pro:
         1. Manage UI with DOM Document :
             1.1 : use getElementById, XPath to retrieve widget
resource.getEObject(<id>) works too.

             1.2 :  use addEventListener to add click event
EMF also supports notification.  I'd argue it's a simpler and more powerful notification model; it can be used to implement undo support, for example.

             1.3  : use  createElement, appendChild to add  widget  to the UI at runtime, use removeChild to remove widget.
Any proper model supports this...

        2. DOM Document API is knowed by a lot of pepople who develop Web with _javascript_.   
It always seems that people don't want to use DOM though.  It's not a pretty sight.  It's not even simple...

  

     cons:
         1. (Today) : doesn't provide model (XSD, XMI...) to generate TK-UI Element (ex : HTMLInputElementImpl).

So EMF is attractive for the model but I think taht Eclipse E4 must think about developer who wants use API to manage Decalarative UI.
Do you prefer use EMF API or DOM API to manage UI?
DOM is pretty horrible, don't you think? :-P  It's like using a stone and a sharp stick as your tools...


With the 2 solutions (EMF, DOM), we must develop some code to bind (EMF java model (Textbox)/DOM Element)
with SWT Text widget. So we need develop something.
Yes, either way...


JFace Databinding seems good to manage that. It exists (EMF Jface Databinding project) and me I have developped
(DOM JFace Databinding).

I hope this topic will interest some people.
Hopefully I'm not being too closed minded. I do rather dislike DOM, so it's easy to be biased against it...

Regards Angelo

_______________________________________________ eclipse-incubator-e4-dev mailing list eclipse-incubator-e4-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev

_______________________________________________
eclipse-incubator-e4-dev mailing list
eclipse-incubator-e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev