[Jboss-dev-forums] [Design of JBossXB] - Re: POJO Schema parsing

[<ale...@jb...>]

"ad...@jb..." wrote : Is it possible for the parser to understand this or is this just something that
  | isn't guaranteed to work with xml?
  | 
  |   | <map>
  |   |    <key/><value/>
  |   |    <key/><value/>
  |   |    <key/><value/>
  |   | </map>
  |   | 

So, there are several issues with maps:
1) representation of entries in XML
2) unmarshalling entries (representation of entries in Java)
3) configuration, e.g. with xsd annotations, etc

1) Representation in XML
Probably, the most natural one is to have an element that wraps key/value pair, e.g. that represents the entry. This is what you currently do.
I don't see a problem with having "complex" keys and values. A key element is unmarshalled (be it of a complex or a simple type) and used as the key, the same for the value element.

Another representation is actually your question. I don't have tests for this but it's possible as long as you can rely on the order of the elements in the sequence, i.e. after the key element we always have the corresponding value element. In XSD, when you define the type of the map, you have to use sequence compositor (other kinds of compositors are 'choice' and 'all'). If the compositor is 'all', the order of the elements in XML content is not guaranteed (SAX parser of course will still report elements in the order they appear in the XML content). This is important if we want to make sure that if an XML content is valid we can guarantee the unmarshalling result.
How to unmarshal this? Create an entry object when the key element starts, complete and add the entry to the map when the value element is parsed.

I was thinking about adding a convenient API for unmarshalling a sequence of elements (w/o a wrapper element) into one object but didn't want to complicate the API too early. I think, it'll be added in the future.

2) Unmarshalling of and Java representation of entries
In the approach we use currently, we create objects ahead, i.e. when an element starts we create an object and then add data to it when we parse the content of the element.
The disadvantage of this approach is that sometimes we have to create temporary container objects, like a map entry object (as you do) which we actually don't need or a container for constructor arguments for classes that don't have default no-arg constructors.
In general, there is no way you can avoid an 'entry' object in this approach.

A bit of theory... another approach would be to expose the stack of objects (which is present anyway) to unmarshalling handlers. And instead of requering an element handler to return an object from startElement (or whatever it's called), let the handler to push an object (or maybe even several objects into the stack). Attribute values, text content and child elements would also be pushed into the stack. In the endElement, the element handler would pop objects from the stack and do whatever is needed, i.e. pop key and value from the stack and add them to the map, pop ctor arguments and create an instance, etc.
I had one prototype of this approach but the API was a bit complex and error-prone. Though, maybe it was just a bad try.

3) configuration, xsd annotation or something else
I am also actually not sure atm how it would translate into xsd annotations. But I believe it's possible :)

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3877311#3877311

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3877311