Hi,
As you say the problem is with the name and scope of the resulting Java class. BTW, this problem also has the potential to occur with the use of anonymous xs:complexType's too. :-(
In the past I have also given this some thought. I found myself thinking of it a scoping solution rather than a name mangling one. The idea I had a was to consider treating anonymous schemas types as Java inner classes. Then of course the name doesn't matter as the inner class must always be qualified by the containing/parent class. So for your anonymous enumeration simpleType.
Element1 element1 = new Element1();
element1.setThing(Element1.ThingType.SOMETHING);
Element2 element2 = new Element2();
element2.setThing(Element2.ThingType.LOTSOFTHINGS);
Then say you used an anonymous complexType instead.
Element1 element1 = new Element1();
Element1.Thing element1Thing = element1.new Thing();
element1Thing.setXYZ(...)
element1Thing.setABC(...)
element1.setThing(element1Thing);
Element2 element2 = new Element2();
Element2.Thing element1Thing = element2.new Thing();
element2Thing.setXYZ(...)
element2Thing.setABC(...)
element2.setThing(element2Thing);
Not that to create instances of either of the Thing classes, you need an instance of the parent class. Of course we could have made Thing a static inner class. Either way would work fine.
When you look at it in code, it's not all that different from the name mangling solution. Although in terms of source files it is less. This does make browsing the packages classes easier as the classes for the anonymous types are defined within the parent class file that they relevent to. Also I think perhaps an inner class approach has a clearer parallel with anonymous schema types.
Andy Fawcett.
-----Original Message-----
From: Arnaud Blandin [mailto:[EMAIL PROTECTED]]
Sent: 25 September 2001 18:17
To: [EMAIL PROTECTED]
Subject: Re: [castor-dev] Source Generator with xs:enumerations
Hi Owen,
this is a known problem and we really need to come up with a solution about enumeration.
We need a full support for it but also to prevent name collision.
Your solution is one solution we thought about, another one is to use the source generator binding file
which hopefully will be in Castor 0.9.4 (no release date yet),
Arnaud
-> -----Original Message-----
-> From: Owen [mailto:[EMAIL PROTECTED]]
-> Sent: Tuesday, September 25, 2001 6:06 AM
-> To: [EMAIL PROTECTED]
-> Subject: [castor-dev] Source Generator with xs:enumerations
->
->
-> Hi,
->
-> I've just been playing with the source generator with a schema I have to
-> write an app
-> around, and have noticed a bit of a problem with the way that castor
-> generates the
-> type classes for xs:enumerations in attribute restrictions. If one has
-> more than one
-> SimpleType in different elements, but with the same name only one of the
-> classes
-> gets generated becuase castor only names the class after the SimpleType.
->
-> E.g. If one has
-> <xs:element name="Element1">
-> <xs:complexType>
-> <xs:attribute name="thing" default="Something">
-> <xs:simpleType>
-> <xs:restriction base="xs:string">
-> <xs:enumeration
-> value="Something"/>
-> <xs:enumeration
-> value="SomethingElse"/>
-> <xs:enumeration
-> value="SomethingElseAgain"/>
-> </xs:restriction>
-> </xs:simpleType>
-> </xs:attribute>
-> </xs:complexType>
-> </xs:element>
->
-> <xs:element name="Element2">
-> <xs:complexType>
-> <xs:attribute name="thing" default="AnotherThing">
-> <xs:simpleType>
-> <xs:restriction base="xs:string">
-> <xs:enumeration
-> value="AnotherThing"/>
-> <xs:enumeration
-> value="YetAnotherThing"/>
-> <xs:enumeration
-> value="LotsOfThings"/>
-> </xs:restriction>
-> </xs:simpleType>
-> </xs:attribute>
-> </xs:complexType>
-> </xs:element>
->
->
-> A class called ThingType will be generated, but only one! Whilst this
-> probably isn't a good piece of
-> schema design anyway, it is (it seems) legal, and I'm stuck with it...
->
-> I've made some changes to the source I've got here to solve the problem,
-> but I would appreciate
-> some comments from others on the way I've gone about it, as it smells of
-> hack to me.
->
-> What I've done is to bestow AttributeDecl with awareness of its
-> parent (in
-> the form of a struct), and
-> have the source factory make the class name [element name][attribute
-> name]Type.java, if the
-> simple type in question happens to be inside an element.
->
-> If people want I'll dust off my somewhat shaky grasp of CVS and try and
-> post a diff file wilth my
-> changes.
->
-> Cheers,
-> Owen
->
-> -----------------------------------------------------------
-> If you wish to unsubscribe from this mailing, send mail to
-> [EMAIL PROTECTED] with a subject of:
-> unsubscribe castor-dev
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
