Re: [wtp-incubator-dev] EMF2DOMSSE

["Jesper S. Møller" <jesper@xxxxxxxxxxxxx>]

David Carver wrote:
> If interested here is what the current model that will try to 
> implement this concept looks like:
>
> http://imagebin.org/30938
OK, I see the difference. The code I did for Mule IDE was in fact 
totally generic with respect to the EMF model in use, you just had to 
switch the ResourceImpl in use, so I was mapping the DOM into semantic 
model, using the XML mapping info in the EMF model, which made it 
really, really hard.

A word of warning: Be careful with the undo functionality. The 
EMF2SSEDOM stuff uses the "old" undo mechanism which should be 
sufficient for simple editing, but if you add the EMF Transaction stuff 
and its undo manager as well, you'll be recording undo information for 
both the text buffer AND the EMF model, which will get you into all 
kinds of trouble. One model (the text model) ought to be enough for both 
models.

-Jesper
> Dave
>
>
> Konstantin Komissarchik wrote:
> > I would be interested in hearing more about implementing the wrapper 
> > solution using EMF. Do you end up letting EMF generate the model and 
> > then hand-replacing the implementations of various methods with calls 
> > to DOM?
> >
> > 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 12:46 PM
> > To: konstantin.komissarchik@xxxxxxxxxx
> > Cc: WTP Incubator Dev list
> > Subject: Re: [wtp-incubator-dev] EMF2DOMSSE
> >
> > Konstantin Komissarchik wrote:
> >  
> > > 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?
> > >     
> > The problem is that the offset information is completely different
> > between the VEX Visual Editor and the DOM Structured Text Editor. They
> > are representing two different types of models though modeling similar
> > concepts.
> >
> > However, I'm doing something similar to what you had suggested after
> > talking with Ed Merks, basically doing a wrapper, and handling the
> > notifications within the EMF classes themselves. It's similar to the
> > wrapping concept that you mentioned earlier. I originally thought about
> > just extending the existing SSEDOM to handle the other information I
> > needed (i.e. different offsets, etc) but that was going to mean
> > reimplementing much of the WTP DOM implementation which was more than I
> > wanted to deal with.
> >
> > He does something similiar with the org.eclispe.xsd code, and so I'm
> > basing some of it off of that implementation. So I'm seeing how the wtp
> > xsd editor and the emf based xsd editor from wtp keep in synch.
> >
> > Dave
> >
> >
> >
> >
> >   
>
>
> _______________________________________________
> wtp-incubator-dev mailing list
> wtp-incubator-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/wtp-incubator-dev