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
|
