Classes generated for schema types which have inheritance by restriction could
better implement the restricted methods
----------------------------------------------------------------------------------------------------------------------
Key: XMLBEANS-261
URL: http://issues.apache.org/jira/browse/XMLBEANS-261
Project: XMLBeans
Type: Improvement
Components: Binding
Versions: Version 2.1
Environment: All
Reporter: Lawrence Jones
Priority: Minor
Consider e.g. the schema in
http://davidbau.com/archives/2003/12/18/the_design_of_xmlbeans_part_3.html,
"Inheritance by Restriction" (although it's easier if you change the types of
the elements to be "xs:string"). The type derived2 derives by restriction from
type derived1 and the restriction is such that an element which was optional in
derived1 must no longer be present in derived2.
Currently a getter / setter set of methods are generated on derived1 and not
overridden on derived2. Hence derived2 has the same functionality as derived1
i.e. the setter works and sets an element which should not be present in
derived2, and the getter will get that element if it is present.
According to the above article the getter should always return null. The
functionality of the setter is not defined.
This JIRA is to request updating this functionality. The setter for derived2
should override the derived1 setter and could do:
a) nothing (i.e. silently not set anything and return)
b) return an UnsupportedOperationException (or maybe a similar RuntimeException
specific to XmlBeans - note: a RuntimeException would not require changes to
the throws clause)
c) actively make sure that there are no such elements in the store and return
(either an exception or just return) after that
The getter too should be overridden and should:
a) just return null, or
b) actively make sure that there are no such elements in the store and return
null
But there are other things to consider:
If, say through the cursor API, the user does manage to insert this element
into the underlying store - should the getter still return null? Should a call
to xmlText() or toString() or any other method of producing the XML write out
the element as it is in the store (which is the approach we've taken for
everything else) or should we try to remove any such elements before printing
out?
What if the derived1 type allowed maxOccurs>1? Then we also have to do the
above for array setters/getters (and the list getters/setters for JDK1.5).
What happens if someone sets up derived3 which inherits from derived2 by
extension and "re-enables" those elements which were in derived1?
Offhand I agree that the current functionality of allowing the setters/getters
to inherit the parent's functionality is odd and not very user-friendly. But
Java does not map easily to "inheritance by restriction" and I think we need to
figure out (at least) all the things above before we implement an update to the
functionality.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
