[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [wtp-incubator-dev] EMF2DOMSSE
|
David Carver wrote:
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.
I don't quite follow what you mean about offset information...
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.
It sounds to me like you are looking to implement the same kind of
technique as was used in the Mule IDE, where an adapter layer is used.
The adapter layer uses the meta-information present in the ECore model,
and effectively uses the XMLSave and XMLLoad implementations (and
related helpers) to provide much of this mapping - EMF adapters added to
update the SSE DOM and SSE DOM listeners which update the ECore model.
We actually made it update an EMF model so well that a GMF based editor
could pick up the changes. BUT the framework ended up mirroring lot of
generic EMF save/load code, and it was following the old (EMF 2.3)
metadata, not including the latest extensions to the XML metadata added
by Ed and others.
-Jesper
