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 <[EMAIL PROTECTED]> > 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 > <http://tk-ui.sourceforge.net/>to manage Decalarative UI and set pro/cons > for EMF and TK-UI. > > In Binding XML to > Java<http://www.theserverside.com/tt/articles/article.tss?l=BindingXMLJava>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 [EMAIL > PROTECTED]://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev > > > _______________________________________________ > eclipse-incubator-e4-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev > >
_______________________________________________ eclipse-incubator-e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
