This all depends on if your subclass is just a Java subclass with, for
example, some convenience methods, or if it is a real SDO subtype (with
additional properties). If you just want to add some methods in your
subclass, in other words, provide your own implementation class for the
type, then simply manually changing the factory method to return your
subclass, should work.
If, on the other hand, you want a real subtype, then you should just
generate the subclass. For example:,
<xs:complexType name="TBase">
<xs:sequence>
<xs:element name="p1" type="xs:string"/>
</xs:sequence>
</xs:complexType>>
<xs:complexType name="TSub">
<xs:complexContent>
<xs:extension base="TBase">
<xs:sequence>
<xs:element name="p2" type="xs:string"/>
</xs:sequence>
</xs:complexContent>
</xs:complexType>
If you generate code for both these types you will have 2 implementation
classes, TBaseImpl and TSubImpl which extends TBaseImpl. If you tried to
hand code TSubImpl yourself, you would need to write the code pretty much
as generated, or it wouldn't work properly, so I'm not sure there's any
value in doing that.
Regarding your previous question about noExtensibility. I'm not sure what
happened with the option, but it's not really very interesting. Using it
would basically say that there can be no subtypes of the generated type -
i.e., the class would be final. The purpose of ExtensibleDataObjectImpl ,
which is used by default, is to allow dynamic SDO types to be subtypes of
statically generated SDO types. For example, if you only generated type
TBase, above (but not TSub), then if you create an instance of TSub (e.g.,
using the DataFactory.create() method), then even though TSub has no
generated class itself, SDO will create an instance of TBaseImpl (the
static base class), instead of DynamicDataObjectImpl, the default dynamic
implementation class. The benefit is that all the base properties are
implemented in the static class, only the TSub methods are implemented
dynamically. If you look at class ExtensibleDataObjectImpl, you'll see that
it provides the data structure for storing the dynamic subtype's
properties. If ExtensibleDataObjectImpl was not used as the base, there
would be nowhere to store the extra dynamic data.
Frank.
"Millies, Sebastian" <[email protected]> wrote on 10/05/2010
12:42:06 PM:
> [image removed]
>
> RE: Extending generated SDO implementation classes
>
> Millies, Sebastian
>
> to:
>
> user
>
> 10/05/2010 12:45 PM
>
> Please respond to user
>
> Hello there,
>
> let me rephrase my third question (about subclassing) from my original
post
> in the context of the following response in another thread:
>
> >From: Frank Budinsky [mailto:[email protected]]
> >Sent: Tuesday, October 05, 2010 4:31 PM
> >To: [email protected]
> >Subject: Re: [SDO] Samples for notification feature / register ?
> >
> [snip]
> >Factory.register() is used to define types with static
> implementation classes.
> >Load from XSD is used for dynamic SDO types.
> >
> >Frank
>
> So how do I make the factory produce objects of a subclass of the
> generated class,
> for some specific type? Would it be enough to subclass the factory
> and override the
> create(typenumber) method to return the subclass?
>
> I guess not, because initializeMetaData() calls initializeType()
> with the instance class
> as its second argument. Unfortunately, the instance class literal is
> hard-coded in the
> generated coding and not obtained from a non-final method. So it
> seems I am still forced
> to manually change some generated coding when subclassing a
> generated data object. Is that
> correct?
>
> -- Sebastian
>
> > -----Original Message-----
> > From: Millies, Sebastian
> > Sent: Tuesday, October 05, 2010 1:54 PM
> > To: '[email protected]'
> > Subject: Extending generated SDO implementation classes
> >
> > Hello there,
> >
> > I have three questions about this topic, one regarding the up-to-
> > dateness of
> > the SDO FAQ, one regarding the XSD2JavaGenerator, and one regarding the
> > use
> > of factories for extensions to generated classes.
> >
> > The SDO FAQ still states:
> >
> > "2) I cannot (yet) simply subclass a generated SDO class, this may be
> > addressed in TUSCANY-513"
> >
> > while TUSCANY-513 has been resolved in 2007 for Java-SDO-1.0, and
> > Tuscany 1.6 presumably includes
> > Java-SDO-1.1.
> >
> > In the generated code, extensibility behaviour is the default, as the
> > base class for generated
> > SDOs, DataObjectBase, extends ExtensibleDataObjectImpl. However, the
> > generator option
> > "-noExtensibility" which is mentioned in TUSCANY-513 is not accepted by
> > the generator.
> >
> > So here are the first two questions:
> > a) How can I (or someone else) update the FAQ
> > b) has the generator ever been updated with that option?
> >
> > Among the generated classes, there is a factory class with a create
> > method, e. g.:
> > public DataObject create(int typeNumber)
> > {
> > switch (typeNumber)
> > {
> > case TYPE1: return (DataObject)createType1();
> > case TYPE2: return (DataObject)createType2(); // (*)
> > default:
> > return super.create(typeNumber);
> > }
> > }
> >
> > Here is the third question:
> > Now, when I extend the generated implementation class of type 2, and
> > want to use that
> > subclass everywhere instead of the generated class, can I simply edit
> > the factory? e. g.
> > replace line (*) with
> > case TYPE2: return createSubclassOfType2();
> > where createSubclassOfType2() is not a generated method but defined by
> > me?
> >
> > -- Sebastian
> >
> >
> >
>
