RE: alternate representations of collections in XMLBeans??
Tim, I would recommend using the extensions, otherwise modifying the generated code is definitely possible but missing even a small thing would break the code. Back to using extensions, if one wants to store a state he can do it by using XmlBookmark which stays with the xml entity even if moved. In your case the hash map should be stored on metadata element. Also the pre/post Set methods are called every time the document is about to change, so youll get calls for all creation/modification/deletion events, made through XmlObject interfaces. Modification through other interfaces like XmlCursor or DOM will not trigger the calls to the pre/post Set methods. Cezar From: Tim Parker [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 28, 2006 1:11 PM To: user@xmlbeans.apache.org Subject: alternate representations of collections in XMLBeans?? The XMLBeans representation of a collection (for something with a maxOccurs GT 1) is a bit limiting... I'm looking to extend it to look more like a Map interface... and I'm hitting some brick walls... For discussion sake, I'll use a structure with three fields: struct foo { int ID; String name; HashMap metadata; } The 'metadata' field contains arbitrary name/value pairs - for simplicity we'll say 'name' and 'value' fields in the hashmap are always strings... The obvious (to me, at least)schema for this is something like: xs:complexType name=NVP xs:sequence xs:element name=Value type=xs:string/ /xs:sequence xs:attribute name=Name type=xs:string/ /xs:complexType xs:complexType name=NVPCollection xs:sequence xs:element name=Entry type=my:NVP minOccurs=0 maxOccurs=unbounded/ /xs:sequence /xs:complexType xs:complexType name=testCase xs:sequence xs:element name=ID type=xs:int/ xs:element name=name type=xs:string/ xs:element name=metadata type=my:NVPCollection/ /xs:sequence /xs:complexType I could build another layer on top of this, butthis could get ugly- What I really need is a way to extend NVPCollection so I can address items by name (like in a HashMap) rather than by position... The ideal would be something like (assuming that we have a mechanism to bind the 'name' field to the map key and the 'value' field to be the one of interest)... NVPCollection thisCollection; // some magic here to get the collection populated... someValue = thisCollection.GetByMap(someArbitraryName); Or we could save some binding complexity by doing ...GetByMap(someArbitraryName,value), saying get the field 'value' from the collection member whose key fieldcontains 'someArbitraryName' (The presumption is that the binding to the key field 'name' would need to be established earlier so the map can be maintained) As I read the documentation, I could build an extension like this, but I'm hosed if I want to do anything more sophisticated than a linear search through the collection on each 'get' call - Unless I'm missing something, I need a place to put an instance-specific HashMap object to maintain mapping between the key field ('name') and the array index... more than a little difficult with the 'static method' requirement for the extension (Not to mention the population problem for the HashMap object itself, but a preSet or postSet implementation would work as long as I never try to delete anything).. Presumably I could also build an 'extendedNVPCollection' class, based on the NVPCollection class generated by XMLBeans, but how would I wire that back into my (XMLBeans-generated) 'testCase' class? I don't want to get into creating wrapper classes for every layer... I tried ignoring thedon't touch - generated code warningsand added some stuff directly to the generated classes for the NVPCollection object, but things started breaking- I'm not sure if the problem is a flaw in my hacking or a fundamental problem I won't solve, so I'm seeking advice -am I tilting at windmills here? Does anyone have ideas as to better ways to do this? === Tim Parker Senior Developer PaperThin, Inc. 617-471-4440 x 203 [EMAIL PROTECTED] www.paperthin.com === PaperThin, Inc. was recently named to KMWorlds 100 Companies that Matter in Knowledge Management. Find out more at www.paperthin.com. ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and
RE: alternate representations of collections in XMLBeans??
Thank you for the quick reply - I'll look into the XMLBookmark idea... Is there anything else I need to know about the preSet and postSet methods? I found documentation (including the operationType values) at http://dev2dev.bea.com/pub/a/2004/11/Configuring_XMLBeans.html- is this the latest-and-greatest, or is there a better and/or more current reference available? Tim From: Cezar Andrei [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 28, 2006 2:29 PMTo: user@xmlbeans.apache.orgSubject: RE: alternate representations of collections in XMLBeans?? Tim, I would recommend using the extensions, otherwise modifying the generated code is definitely possible but missing even a small thing would break the code. Back to using extensions, if one wants to store a state he can do it by using XmlBookmark which stays with the xml entity even if moved. In your case the hash map should be stored on metadata element. Also the pre/post Set methods are called every time the document is about to change, so youll get calls for all creation/modification/deletion events, made through XmlObject interfaces. Modification through other interfaces like XmlCursor or DOM will not trigger the calls to the pre/post Set methods. Cezar From: Tim Parker [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 28, 2006 1:11 PMTo: user@xmlbeans.apache.orgSubject: alternate representations of collections in XMLBeans?? The XMLBeans representation of a collection (for something with a maxOccurs GT 1) is a bit limiting... I'm looking to extend it to look more like a Map interface... and I'm hitting some brick walls... For discussion sake, I'll use a structure with three fields: struct foo { int ID; String name; HashMap metadata; } The 'metadata' field contains arbitrary name/value pairs - for simplicity we'll say 'name' and 'value' fields in the hashmap are always strings... The obvious (to me, at least)schema for this is something like: xs:complexType name="NVP"xs:sequencexs:element name="Value" type="xs:string"//xs:sequencexs:attribute name="Name" type="xs:string"//xs:complexType xs:complexType name="NVPCollection"xs:sequencexs:element name="Entry" type="my:NVP" minOccurs="0" maxOccurs="unbounded"//xs:sequence/xs:complexType xs:complexType name="testCase" xs:sequence xs:element name="ID" type="xs:int"/ xs:element name="name" type="xs:string"/ xs:element name="metadata" type="my:NVPCollection"/ /xs:sequence /xs:complexType I could build another layer on top of this, butthis could get ugly- What I really need is a way to extend NVPCollection so I can address items by name (like in a HashMap) rather than by position... The ideal would be something like (assuming that we have a mechanism to bind the 'name' field to the map key and the 'value' field to be the one of interest)... NVPCollection thisCollection; // some magic here to get the collection populated... someValue = thisCollection.GetByMap("someArbitraryName"); Or we could save some binding complexity by doing ...GetByMap("someArbitraryName","value"), saying "get the field 'value' from the collection member whose key fieldcontains 'someArbitraryName'" (The presumption is that the binding to the key field 'name' would need to be established earlier so the map can be maintained) As I read the documentation, I could build an extension like this, but I'm hosed if I want to do anything more sophisticated than a linear search through the collection on each 'get' call - Unless I'm missing something, I need a place to put an instance-specific HashMap object to maintain mapping between the key field ('name') and the array index... more than a little difficult with the 'static method' requirement for the extension (Not to mention the population problem for the HashMap object itself, but a preSet or postSet implementation would work as long as I never try to delete anything).. Presumably I could also build an 'extendedNVPCollection' class, based on the NVPCollection class generated by XMLBeans, but how would I wire that back into my (XMLBeans-generated) 'testCase' class? I don't want to get into creating wrapper classes for every layer... I tried ignoring the"don't touch - generated code" warningsand added some stuff directly to the generated classes for the NVPCollection object, but things started breaking- I'm not sure if the problem is a flaw in my hacking or a fundamental problem I won't solve, so I'm seeking advice -am I tilting at windmills here? Does anyone have ideas as to better ways to do this? === Tim Parker Senior Developer PaperThin, In
RE: alternate representations of collections in XMLBeans??
That is a good article to read, also check out the tests under test\cases\xbean\extensions. Cezar From: Tim Parker [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 28, 2006 3:08 PM To: user@xmlbeans.apache.org Subject: RE: alternate representations of collections in XMLBeans?? Thank you for the quick reply - I'll look into the XMLBookmark idea... Is there anything else I need to know about the preSet and postSet methods? I found documentation (including the operationType values) at http://dev2dev.bea.com/pub/a/2004/11/Configuring_XMLBeans.html- is this the latest-and-greatest, or is there a better and/or more current reference available? Tim From: Cezar Andrei [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 28, 2006 2:29 PM To: user@xmlbeans.apache.org Subject: RE: alternate representations of collections in XMLBeans?? Tim, I would recommend using the extensions, otherwise modifying the generated code is definitely possible but missing even a small thing would break the code. Back to using extensions, if one wants to store a state he can do it by using XmlBookmark which stays with the xml entity even if moved. In your case the hash map should be stored on metadata element. Also the pre/post Set methods are called every time the document is about to change, so youll get calls for all creation/modification/deletion events, made through XmlObject interfaces. Modification through other interfaces like XmlCursor or DOM will not trigger the calls to the pre/post Set methods. Cezar From: Tim Parker [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 28, 2006 1:11 PM To: user@xmlbeans.apache.org Subject: alternate representations of collections in XMLBeans?? The XMLBeans representation of a collection (for something with a maxOccurs GT 1) is a bit limiting... I'm looking to extend it to look more like a Map interface... and I'm hitting some brick walls... For discussion sake, I'll use a structure with three fields: struct foo { int ID; String name; HashMap metadata; } The 'metadata' field contains arbitrary name/value pairs - for simplicity we'll say 'name' and 'value' fields in the hashmap are always strings... The obvious (to me, at least)schema for this is something like: xs:complexType name=NVP xs:sequence xs:element name=Value type=xs:string/ /xs:sequence xs:attribute name=Name type=xs:string/ /xs:complexType xs:complexType name=NVPCollection xs:sequence xs:element name=Entry type=my:NVP minOccurs=0 maxOccurs=unbounded/ /xs:sequence /xs:complexType xs:complexType name=testCase xs:sequence xs:element name=ID type=xs:int/ xs:element name=name type=xs:string/ xs:element name=metadata type=my:NVPCollection/ /xs:sequence /xs:complexType I could build another layer on top of this, butthis could get ugly- What I really need is a way to extend NVPCollection so I can address items by name (like in a HashMap) rather than by position... The ideal would be something like (assuming that we have a mechanism to bind the 'name' field to the map key and the 'value' field to be the one of interest)... NVPCollection thisCollection; // some magic here to get the collection populated... someValue = thisCollection.GetByMap(someArbitraryName); Or we could save some binding complexity by doing ...GetByMap(someArbitraryName,value), saying get the field 'value' from the collection member whose key fieldcontains 'someArbitraryName' (The presumption is that the binding to the key field 'name' would need to be established earlier so the map can be maintained) As I read the documentation, I could build an extension like this, but I'm hosed if I want to do anything more sophisticated than a linear search through the collection on each 'get' call - Unless I'm missing something, I need a place to put an instance-specific HashMap object to maintain mapping between the key field ('name') and the array index... more than a little difficult with the 'static method' requirement for the extension (Not to mention the population problem for the HashMap object itself, but a preSet or postSet implementation would work as long as I never try to delete anything).. Presumably I could also build an 'extendedNVPCollection' class, based on the NVPCollection class generated by XMLBeans, but how would I wire that back into my (XMLBeans-generated) 'testCase' class? I don't want to get into creating wrapper classes for every layer... I tried ignoring thedon't touch - generated code warningsand added some stuff directly to the generated classes for the NVPCollection object, but things started breaking- I'm not sure if the problem is a flaw in my hacking or a fundamental problem I won't solve, so I'm seeking advice -am I