[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Newsgroup Home]
[news.eclipse.tools.emf] Re: Is there a way to extend EFactories? 
Paul,

Comments below.

Paul Fullbright wrote: 
I have to support several versions of a document, such as below:

foo_1_0.xsd:

<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema targetNamespace="http://www.foo.com"; xmlns:xsd="http://www.w3.org/2001/XMLSchema"; version="1.0">
<xsd:complexType name="foo">
<xsd:sequence>
<xsd:element name="name" type="xsd:string" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
</xsd:schema>

foo_2_0.xsd:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<xsd:schema targetNamespace="www.foo.com"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"; version="2.0">
<xsd:redefine schemaLocation="foo_1_0.xsd">
<xsd:complexType name="foo">
<xsd:complexContent>
<xsd:extension base="foo">
<xsd:sequence>
<xsd:element name="description" type="xsd:string" minOccurs="0"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
</xsd:redefine>
</xsd:schema>


As you can see, foo version 2 simply extends foo version 1.
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.
I would *like* to be able to encapsulate creation of the foo EObject depending on which version of the document I'm dealing with (and I have to deal with both). So it would be helpful if, in addition to model inheritance, I could have EFactory inheritance, such as:

public class FooFactory extends EFactoryImpl {
   ...
   Foo createFoo() {
   ...
}

public class Foov2Factory extends FooFactory {
   ...
   Foov2 create Foo() {   // where Foov2 extends Foo
   ...
}
It still begs the question how you'd know which to use?

I could thus have a foo creation scenario where all I have to do is retrieve the correct factory:

(client code)

   Foo buildFoo() {
       FooFactory factory = determineFactory();
       return factory.createFoo();
   }


Is such a thing possible?
No.
Or is something similar possible?
No.
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.

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. 

Thanks,
Paul