Ok, I got rid of JDOM dependency (which was easy) and also did some
refactoring of XMLEncoder. IMO its API was confusing with so many
encoding options, besides its internal state tracking wasn't
appropriate for tree navigation. As I mentioned in CVS commit notes,
my new code is still rather dirty, but I think I am on the right track.
General notes about XML API:
1. Would be nice to take advantage of our new ClassDescriptors for
the XML mapping. This is more of a long term goal.
2. Even though the encoder is DOM-based, it would be nice to have
streaming API for it. Otherwise it will not scale to large numbers of
objects.
3. XMLDecoder DataContext use is too simplistic. We need something
more generic that can be used for transferring existing objects, not
just new. Again there is synergy with multi-tier stuff. I wonder if
we should make XMLSerializable and Encoder/Decoder into a graph
serialization interface that is not XML specific.
I think 2 and 3 (in some form) are a must have for a final production
release of 1.2.
Andrus
On Oct 14, 2005, at 5:55 PM, Kevin Menard wrote:
> Andrus Adamchik wrote:
>
>> Kevin, et al.
>>
>> Here is an XMLDecoder patch that took me about 20 minutes to
>> create. It
>> replaces JDOM with DOM. (OK, I hit Ctrl-F, so it has more changes
>> than
>> there really is). Also I cheated a bit - I commented out parts that
>> required changing MappingUtils ... so it passes all unit tests
>> except
>> those that involve mapping. It should be similarly easy to port
>> encoder, just need to borrow pretty-print code from Xerces
>> examples or
>> something.
>>
>
> Well, that's certainly good to hear. I did expect it to take much
> longer than that.
>
>
>>
>> One of the caveats is that missing attribute values are returned
>> as ""
>> by DOM, while they are returned as "null" from JDOM. Actually it
>> turned
>> out that it saved some code as we no longer need to do null
>> checking :-).
>>
>> I volunteer to proceed with the rest of the port, just wanted to
>> run it
>> by you first. Any comments?
>>
>
> Looks good. Your XMLUtil class is a nice wrapper. Given this, I'd
> say
> go with it. JDOM apparantly wasn't gaining us much as I thought :-P
>
> --
> Kevin
>
>
This archive was generated by hypermail 2.0.0 : Mon Oct 24 2005 - 00:53:04 EDT