> This is a bug. Apparently my unit tests weren't complete. I'll add
> a new one and fix this. Thanks. FYI, you can report things like
> this against CAY-261.
OK, sorry. I am not used to Cayenne bug submission mechanisms yet :)
> The reason for this was so that the public API does not rely on
> JDOM. If you can suggest a better way to handle this, I'm open to
> suggestions. The use of JDOM right now should be considered an
> implementation detail however.
I see the problem or your intention respectively.
But there is a problem with the whole logical implementation then. It is
now possible to normalize CayenneDataObjects as an XML stream. I am
writing a few of these strings as part of a bigger XML into one file. Just
a normaly backup mechanism.
Which brings me into a problem trying to read back the content of my XML
since I read that file with JDOM and not as a String. There is
unfortunately no method to get a string from a node in JDOM. Which is a
detail however :) But I don't see it as practical - at least for me - to
somehow read an XML file as a string, parse that string so that I can put
some substrings thereof into a function which then parses that as an XML
node. (Perhaps I should write one file for every list.)
I'd love to be able to give a Node to the Decode method and get a list of
Objects out of that. But I see that this is not the intended usage. But I
am having problems to see how I should use the encoder/decoder otherwise.
I dont know how to solve this in Cayenne. For me I will most probably
write some method like one of your internal ones accepting nodes and use
that as an immediate solution.
Regards,
Adrian
This archive was generated by hypermail 2.0.0 : Tue Jul 26 2005 - 05:19:30 EDT