[news.eclipse.tools.emf] Re: Is there a way to extend EFactories?

[Ed Merks <Ed.Merks@xxxxxxxxx>]

Paul,

Comments below.


Paul Fullbright wrote:
> Ed,
>
> > It's nice that the schema has a version attribute, but that doesn't 
> > help you distinguish which version any particular instance will be 
> > using.
>
> It does help actually.  We use a custom content describer that 
> introspects the root element, namespace, and version,
So the document has a version?  The schema version attribute doesn't help...
> and then we associate the resource with the client objects.  We'd just 
> like to not have to create twice the number of client objects (we have 
> rather a lot of objects per document).
>
> > It still begs the question how you'd know which to use?
>
> (See above)
>
> > > Is such a thing possible?  
> > No.
> > > Or is something similar possible?
> > No.
>
> Hmm.  Unfortunate.
>
> > >   The encapsulation of object creation is the key here for me.
> > Certainly object creation is centralized in XMLHelperImpl's   public 
> > EObject createObject(EFactory eFactory, EClassifier type) but without 
> > information in the document, it's not clear how that would help.
>
> I'll take a look into this.  Thanks.
>
> > Typically "binary" incompatible schema changes should be associated 
> > with a change to the namespace and that of course makes the problem 
> > very easy to solve because you'd have a different package and 
> > different factory for that.
>
> Talk to Sun.  :)  Though all the schema changes are not incompatible.  
> Anything valid under v1 will also be valid under v2 (if my example 
> didn't have this, that's my fault.)
So can't you just use the new model for reading old instances then?
> Thanks,
> Paul