Hi Mike,

ok, now I understand your problem a little bit better.
Though my problem is based on a badly defined schema (but where I
do no have any control over) and thus I can't blame XmlBeans,
I do think that both problems could be solved by a modificated
extension mechanism:

If I have two type A,B with the same element 'X', I could extract
a common interface BaseInterface with two methods 'getX' and 'setX'.
Then in the xsdconfig I specifiy:

 <extension for="*">
  <interface name="BaseInterface">
    <staticHandler>test.MyHandler</staticHandler>
  </interface>
 </extension>

In the handler class I could then simply redirect any call to the
Original XmlObject.
The only problem here is that XmlBeans does not *replace* the methods
in the generated interface but generate additional ones, in this
case 'getX2' and 'setX2'.
So it would solve my problem to tell XmlBeans to *not* generate
additional methods but either delegate the standard (getX,setX) methods
to the handler or by using no handler at all, maybe like:

<extension for="*">
  <custom-interface name="BaseInterface" />
</extension>

This is what you ment right? But why not include this in the xsdconfig?
I think it would perfectly fit and since the code for the extension
stuff is already present, it should be not too complicated to implement.

Maybe file a RFE for that? Or is it even an error, that I can't use a
handler for the standard methods?

Robin.


Mike Skells wrote:
Hi Robin,
What I am looking for is primerally at the interface level, so I would like
to be able to define is to define an interface based on the attribute group
or the group and have the generated interface extend the interface
representing the group (as it is contained functionallity. I am unconcerned
that the code does not reuse the group as an object, I am only concerned
with the interface

This seems similar to the feature for allowing a static handler to be
defined for user defined methods, but in this case the methods are defined,
and I am loosing all the benifits of strong typing and object reuse. What I
need to do is to generate the interface of the schema type and reference the
schema in the elements/ complex types that include it

It seems that the problem that you describe could be modelled as xs:group.
This is a reusable structue that can be part of the content of a complex
type. It does not define attributes, hence the sister object of the
attributeGroup (shame the w3c couldnt have a group containing attributes - I
am sure that there is a reason but I dont know it ...

I find the group a useful concept to allow for the definition of a structure
in a reuable manner. It saves in documentation and copy-paste errors.

I cannot see any options in the xsdconfig schema file that relate to this.
I would be happy to use or develop them, however the schema documentation
seems a better place for this I think, particually as there is only the
SchemaType that mimics the group structure

Something like
<xs:group name="abc">
  <xs:annotation>
    <xs:documentation>this is really useful</xs:documentation>
    <xs:appinfo>
      <xb:include-as-interface interface-name="com.foo.Bar"/>
    </xs:appinfo>
  <xs:annotation>
  <xs:sequence>
    <xs:element name="ele1" />
    <xs:element name="ele2" />
...
  </xs:sequence>
</xs:group>

I would be willing to do some development to accomplish this.

At the moment my only option is to do so kind of post processing on the
souce/class files to accomplish this which seems to me totally the wrong way
to go.

Can anyone comment as to how much work this would be?

Mike


-----Original Message-----
From: Robin Sander [mailto:[EMAIL PROTECTED] Sent: 13 September 2005 16:13
To: dev@xmlbeans.apache.org
Subject: Re: representation of xs:group and xs:attributeGroup, and polymorphic classes


Hello Mike,

I haven't used element-groups or attribute-groups yet, but have a similar problem: when a schema defines many different named types (or types in different schemas/namespaces) which all have identical content it would be great to be able to tell XmlBeans to use the same class for all those types. Maybe by manually specifying them in xsdconfig. Or is this already possible by mapping different QNames to the same java name? (I havent't tried this yet ... my fault) Considering your problem: XmlBeans mimics the type hierarchy of a schema, not the elements, so I think it would not be easy to map a group of elements to one class. But I'm not sure about that, maybe a kind of pseudo-type could be used internally for that purpose.

regards,

Robin.



Mike Skells wrote:

Hi,
I have reposted this due to the underwhelming response :(

Do people think that this is a good idea?
Is it available currently or should I file an RFE?

...

Is anyone out there?


Mike


--------------------------------------------------------------
----------

   *From:* Mike Skells [mailto:[EMAIL PROTECTED]
   *Sent:* 08 September 2005 14:57
   *To:* dev@xmlbeans.apache.org
   *Subject:* representation of xs:group and xs:attributeGroup, and
   polymorphic classes

   Hi,
I am generating a series of java classes based on

schemas which make

   heavy use in groups and attribute groups
Is there any way to get the generated classes to marks and reuse
   this commonallity
   It woudl seem to me that these would map to other interfaces
e.g.

   <xs:complexType name="WorkflowRulesType">
     <xs:complexContent>
       <xs:extension base="local:WorkflowRules-interfaceType">
         <xs:sequence>
           <xs:group ref="local:workflow-content"/>
         </xs:sequence>
         <xs:attributeGroup ref="local:workflow-attributes"/>
       </xs:extension>
     </xs:complexContent>
   </xs:complexType>

   ...

   <xs:complexType name="WorkflowType">
     <xs:complexContent>
       <xs:extension base="local:Workflow-interfaceType">
         <xs:sequence>
           <xs:group ref="local:workflow-content"/>
         </xs:sequence>
         <xs:attributeGroup ref="local:workflow-attributes"/>
        </xs:extension>
     </xs:complexContent>
   </xs:complexType>

   I get a class

public interface WorkflowRulesType extends

WorkflowRulesInterfaceType

   and
   public interface WorkflowType extends WorkflowInterfaceType
each with an identical set of methods that relate to the content Wouldnt it be more logical to get
   public interface WorkflowsRulesType extends
   WorkflowsRulesInterfaceType, WorkflowAttributes, WorkflowContent
public interface WorkflowsType extends

WorkflowsRulesInterfaceType,

   WorkflowAttributes, WorkflowContent
Is there a way to get xmlbeans to generate the

additional methods to

   aid the polymorphic behaviors
Mike


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]






---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to