|Re: De-serialization of extended eCore models [message #660099 is a reply to message #660080]
||Wed, 16 March 2011 19:28
| Ed Merks
Registered: July 2009
> Thanks Ed. Let me try again.
>>> The reason I created the uri2 eCore model and extended the uri1
>>> eClasses was because I cannot alter the uri1 eCore model to add
>> Why not?
> In my case, the base eCore model is coming from open source. Even if
> it wasn't, I would imagine that there are plenty of times that people
> would like to enhance an eCore model without modifying it.
>> Yet you're asking for precisely something that's XML which can't be
>> processed in a standard way...
> That's a fair criticism.
>> ... It's not clear why, though. Is it just an aesthetic thing? XML is
>> after all horribly ugly and barely fit for human consumption so
>> trying to make it prettier is a bit like putting lipstick on a pig. ...
> The instances of our models are static files that are always read
> only. They have either been created using xml editors, or generated
> as xml from other sources.
So they're being created in a way that conforms to no schemas...
> They are not created using generated EMF editors.
> We are taking existing model instances and decorating a handful of the
> elements with new attributes.
Because the base model didn't anticipate a need for
> But in the absence of that attribute, a default value is implied.
> It would be so much cleaner to have instances of the child subclass
> after a load for that reason. The particular reason I would like to
> avoid adding an xsi:type attribute to every element is because it
> would make comparing the original model with the decorated one very
> difficult since there may be hundreds of child elements in the xml file.
Or you could look at it as just one more attribute; one that indicates
there will be decorations and what model those decorations conform to,
which seems like a good thing...
>> Is there some existing generated model over which you have no control?
> Are you asking if we could create our own genmodel for the base eCore
Yes. Or your own modified copy of that. In any case, to achieve what
you want, you'd have to do things like specialize
XMLSaveImpl.saveTypeAttribute to skip doing that in certain cases and
you could specialize XMLHelperImpl.createObject to substitute a derived
class for certain cases. Trying setting a breakpoint in these places
and see how they're invoked when loading and saving...
Powered by FUDForum
. Page generated in 0.03647 seconds