Hi Robin, I have filed an RFE http://issues.apache.org/jira/browse/XMLBEANS-203 Please feel free to vote for or ammend it
Mike > -----Original Message----- > From: Robin Sander [mailto:[EMAIL PROTECTED] > Sent: 14 September 2005 12:57 > To: dev@xmlbeans.apache.org > Subject: Re: representation of xs:group and > xs:attributeGroup, and polymorphic classes > > > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
