On Dec 23, 2011, at 10:05 AM, Wolfgang Laun wrote:
> See inline.
>
> On 23/12/2011, tim.quinn_at_oracle.com <tim.quinn_at_oracle.com> wrote:
> [snip]
> >
> > Suppose I have
> >
> > <xsd:choice maxoccurs="unbounded">
> > <xsd:element name="a" type="aType"/>
> > <xsd:element name="b" type="bType"/>
> > </xsd:choice>
> >
> [snip]
> > What JAX-B generates is
> >
> > public List<JAXBElement<?>> get...
> >
> > where it generates the method name.
> >
> > First, what I would really like is for JAX-B to generate
> >
> > List<AType> getA() {...}
> >
> > List<BType> getB() {...}
>
> This loses information which is inherently and unavoidably imposed
> by the XML data model, i.e. the relative ordering of <a>'s and <b>'s
> within their containing parent. If you aren't interested in a relative
> ordering, redefine the XML schema without <xs:choice>.
And if I don't have control over the schema?
It's interesting that you say that because, in this case, the comments
in the schema (it's the Java EE schema for web apps) indicate that the
reason for using choice is to allow the child elements to appear in
any order, and in this specific case at least the ordering does not
matter. Of course in some cases the order in which they appear might
still be important, even though the schema allows them to appear in
any order.
Note that I did not mean to say that I wanted JAX-B to generate *only*
the getA and getB methods. JAX-B could happily generate the getAorB
method as well which would preserve the ordering. But by generating
getA and getB for me JAX-B would allow me concentrate on using the
content rather than writing a handler to get to the content and type
it appropriately so I could then actually use it.
>
> >
> > Second, given that it does not do that I understand that a handler
> can
> > help me here. What strikes me is that JAX-B has all the
> information at
> > build-time that's needed to write the handler. It would be far
> better
> > at doing that than I would be doing so manually.
>
> That's an interesting thought but the generator won't be able to
> generate
> the code doing the actual processing for you. So, how would that be
> merged
> into the generated stuff?
I suppose JAX-B could generate an abstract handler with abstract
methods processA(A a), processB(B b), etc. The element-specific names
could be necessary (rather than just generating process(A a) and
process(B b) in case A and B both turn out to be String, for
example). There could be issues with this approach I'm not seeing but
if so I'm sure there would be solutions to them as well!
- Tim