Andy-
The implementation of the location attribute is a little bit of black
magic as far as I know, though there may be more knowledgeable people
on the list. So implementing any kind of fix related to location (in
my mind) is non-trivial.
As far as unmarshaling the PointErrors before the Points, the
references and identities should take care of that -- though not
having done it myself, I can't guarantee anything (but looking at the
howto, the various nodes all referenced each other, so at some point
there had to be objects created with unresolved dependencies that
eventually got resolved).
An XSLT or JDOM solution may be more comfortable for you. Playing
devil's advocate for a minute here though: if nothing else, Castor
uses a SAX (i.e. event based) parser so the objects must be
unmarshaled in the order they exist in the XML. So if you use a List
(a known iteration pattern), Castor should marshal the list in order,
and thus unmarshaling should happen in order. Just something to think
about.
Good luck.
Stephen
On 12/12/06, Andy Buckley <[EMAIL PROTECTED]> wrote:
Stephen Bash wrote:
> Andy-
>
> Hm... If the PointError objects are coming from a get method in the
> Point class, things might get a little complicated. You could try
> your mapping, though I don't know if location can use a construct like
> "../" (there may be a construct it will honor, but it would require
> looking through the code to determine how the location attribute is
> parsed). I hadn't thought about it before, but location probably
> SHOULD use XPath, but I agree with you that I don't think it does (it
> may use portions of the spec, but I don't think it implements the full
> spec).
I tried setting point.field[name=errors].bind-xml[location] = "../pointerrors"
(if that makes sense) just to see what would happen. Marshalling doesn't
complain, but will build an XML structure like this:
<point>
<..>
<pointerrors>
<pointerror ... />
</pointerrors>
</..>
</point>
Unmarshalling this gives an XML parsing error, for obvious reasons! So the
location does understand "foo/bar/baz" type structures, but doesn't understand
that ".." means "walk back up the tree". Does this count as a bug? Being able
to handle that more general type of location reference would be very useful,
especially if it's not that hard to implement (I don't know what goes on inside
this bit of Castor!). Anyway, now we know :-)
> In your case what is
> lacking is the larger class that contains both the Points and the
> PointErrors as top level classes. Possibly your marshaling code could
> extract the PointErrors and pack them into some Collection along with
> the Points before marshaling. That would probably be easier than
> coding up the XSLT (though that probably depends on a lot of factors).
What worries me there is that the relation is really hierarchical and I
wouldn't want Castor to try and unmarshall the PointErrors before the Points
have been built. I think XSLT (or just using JDOM to move some elements around)
might be the more robust way... unless the location ".."-fix would be easy?
Thanks again,
Andy
--
Andy Buckley: CEDAR @ IPPP, Durham
Work: www.cedar.ac.uk
www.insectnation.org
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
