RE: [wtp-incubator-dev] EMF2DOMSSE

["Konstantin Komissarchik" <konstantin.komissarchik@xxxxxxxxxx>]

Yes, the EMF2DOM infrastructure is definitely built on assumption that you are mapping to specific java types based on element names. Good fit if your model represents a particular schema, but probably not for cases where you are trying to model arbitrary XML.

So why not just use DOM with SSE extensions directly if your editor manipulates generic XML? That gives you structure plus offset information. What would be gained by introducing another model and then having to deal with bi-directional synchronization problems? 

Oracle
Konstantin Komissarchik | Consulting Member of Technical Staff
Phone: +1 425 201 1795 | Mobile: +1 206 898 0611 
Oracle Eclipse Tooling
411 108th Ave NE, Suite 2100 | Bellevue, WA 98004 
 

-----Original Message-----
From: David Carver [mailto:d_a_carver@xxxxxxxxx] 
Sent: Tuesday, November 11, 2008 10:43 AM
To: konstantin.komissarchik@xxxxxxxxxx; WTP Incubator Dev list
Subject: Re: [wtp-incubator-dev] EMF2DOMSSE

Konstantin Komissarchik wrote:
> I would look for examples of EMF2DOM usage in the code that handles serialization of Java EE deployment descriptors, such as WebArtifactEdit. That's what I used as a reference when we tried going down that path in a commercial product I am working on. 
>
> Have to say though, we ended up wasting a lot of time (many months) with that approach and ultimately threw away all the code that we wrote. It was just too unstable. The EMF and DOM models would get out of sync easily and chasing down these bugs was extremely time consuming as the problems weren't exactly easy to reproduce. After sinking a bunch of time into that approach, we ended up concluding that maintaining two models in memory with bi-directional synchronization was just unnecessarily complicated. We ended up implementing a DOM wrapper model approach. We got a nice clean model-based interface that way and only one model in memory (all getters and setters would read/modify DOM nodes directly). Unfortunately, we had to code the model by hand. The only system that I am aware of that can code gen code like that is Apache XMLBeans and we didn't really want to use that for a variety of reasons. Both EMF and JAXB don't handle this scenario. They are good for cases where you have to slurp in contents of an XML file, make some changes and then spit an XML file back out, but are not a good fit for building an XML editor 
>   
Thanks, Konstantin.

Well, the examples I've seen so far assume that you have generated from 
a XML schema or have a particular XML instance that needs to be wrapped. 
So that the elements are named as classes with in the Model. I thought 
about going down the wrapper path, but in a lot of ways the information 
I'm tracking doesn't lend itself well to the wrapper (text offsets are 
tracked differently). What I have is a generic DOM like model in VEX 
(really based off the JDOM model), which has classes for elements, 
nodes, text, comments, processing instructions, etc. The XML that is 
loaded into the model could be anything, from DocBook, DITA, or any 
number of other XML formats.

So what I really need is a way to translate the VEX EMF generic model 
back to the DOM to keep the two in synch. I may have to end up writing 
something else, since it doesn't appear that the current translators and 
emf2dom classes are setup for this use case.