Big shocker that I should respond hey? :-P
Angelo zerr wrote:
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.
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
manage Decalarative UI and set pro/cons for EMF and TK-UI.
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.
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" />
TK-UI manage UI with DOM Document like WebBrowser DOM Document (with
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
And here that I have understood
User describe UI with XMI into Window.xmi like this :
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.
<Textbox value="bla bla bla" />
And it load it with ResourceSet :
URI fileURI = URI.createFileURI(new
Resource resource = resourceSet.getResource(fileURI, true);
Window /* EObject */ window = resource.????;
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
window.getTextbox I would assume...
Textbox textbox = window.????
So here how I have understood the final UI API.
Is it correct?
DOM generally uses more space...
So with EMF UI is managed with Ecore model (EObject...) and custom java
and with TK-UI UI is managed with DOM Document and custom java method
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.
Here pro/cons for EMF and DOM that I see :
1. Provide a model (XSD, XMI..) to define structure of widget
2. Provide a lot of tools to manage EMF.
1. New API to learn for developer (like me) who doesn't know EMF
(but perhaps EMF is very knowed?).
resource.getEObject(<id>) works too.
DOM (TK-UI) :
1. Manage UI with DOM Document :
1.1 : use getElementById, XPath to retrieve widget
EMF also supports notification. I'd argue it's a simpler and more
powerful notification model; it can be used to implement undo support,
1.2 : use addEventListener to add click
Any proper model supports this...
1.3 : use createElement, appendChild to
add widget to the UI at runtime, use removeChild to remove widget.
It always seems that people don't want to use DOM though. It's not a
pretty sight. It's not even simple...
2. DOM Document API is knowed by a lot of
DOM is pretty horrible, don't you think? :-P It's like using a stone
and a sharp stick as your tools...
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?
Yes, either way...
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.
Hopefully I'm not being too closed minded. I do rather dislike DOM, so
it's easy to be biased against it...
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.
eclipse-incubator-e4-dev mailing list