XMLBookmark question...

[Tim Parker <tp...@paperthin.com>]

As a follow-on to the HashMap implementation questions...  I feel like I
may be missing something but... I'm looking at creating an extension
method for my NVPCollection class something like:
 
public String getValueByMap(String keyName)
 
If I hang the hashmap on a bookmark, how do I get the bookmark without
having to do a newCursor() every time?  Or is it OK to run newCursor()
dozens or hundreds of times without risk of performance or memory
problems?  Am I missing something?
 
Tim
 
 

________________________________

From: Cezar Andrei [mailto:cezar@bea.com] 
Sent: Tuesday, March 28, 2006 4:33 PM
To: user@xmlbeans.apache.org
Subject: 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:tparker@paperthin.com] 
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:cezar@bea.com] 
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 you'll 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:tparker@paperthin.com] 
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, but this 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 field contains '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" warnings and 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 
tparker@paperthin.com 
www.paperthin.com 

=================== 

PaperThin, Inc. was recently named to KMWorld's "100 Companies that
Matter in Knowledge Management". 

Find out more at www.paperthin.com <http://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 have received this message in error, please immediately return this
by email and then delete it.
_______________________________________________________________________
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 have received this message in error, please immediately return this
by email and then delete it.