[
Lists Home |
Date Index |
Thread Index
]
Aleksander Slominski wrote:
<snip/>
> as i am writing a review of different XML output libraries for Java it
> is interesting to hear about you work and i am also author YAXOL (yet
> another XML output library) called XmlSerializer so naturally i wanted
> to compare it with Swan.
Thanks for the info. I'm not familiar with that; I'll have to check it
out.
I'll also be interested in seeing your review.
> there is however one aspect that i could hardly understand: am i right
> that Swan builds in memory a node tree (ContainerResult with recursive
> children list)? that tree is then flushed when last child is written for
> parent but that means that for deeply nested trees all earlier children
> of depth lower than current one will be in memory? if i am right then i
> am curious why would you do that (did you consider of XML streaming or
> assumed small XML docs and DOM like memory requirements)?
You are partly right. I did that to provide some flexibility to the
developer. They can retain a reference to an earlier result in the
"stream" (using that term very loosely) and still go back and add
additional content later if it has not yet been flushed to output. But
it doesn't attempt to be a full-fledged tree API, and the application
can control how much gets held in memory via the "flush" and "end"
methods. Note, for instance, in the second example in my original email,
I'm invoking "end()" repeatedly. This keeps flushing accumulated results
out to output so you never have very much held in memory at any one
time. Invoking "flush()" on an ElementResult emits its start tag and any
accumulated children, so far, so you can't go back and add attributes or
namespace declarations, at that point, but you can still add more
children, so long as it has not had its "end()" method invoked as a side
effect of invoking "end()" or "flush()" on some other result object
(which may occur in order to preserve well-formedness of the output).
|
