[jdom-interest] Element and Document serialized forms

[Alex Chaffee]

I didn't see this message before I wrote the last one; please forgive
any patronizing overtones in the last one suggesting you don't
understand OOP :-).

So you seem to think that they should probably be the same class.
Since XMLSerializer is destined for planned obsolescence, why are you
bothering to write it?  

Perhaps it's because of "encoding hassles."  Well, as far as that goes,

(a) any hassles in one will exist in the other, unless you rewrite the
entire functionality to use StringBuffers, which seems kind of silly,

and

(b) the solution to the encoding hassles is for XMLOutputter to have a
property specifying the encoding, like Jason suggested.  Doesn't that
take care of it?  I don't recall your objections except to wring your
hands (said hand-wringing shared by myself and Jason) about flaws in
java.io and in XML, over which we have no control.

For performance reasons, you'll want the standard output methods to
take a stream/writer, and the string output methods to wrap those with
a StringWriter or something.  

Thus they are one.

 - Alex


On Wed, Jul 12, 2000 at 12:19:14PM -0700, Elliotte Rusty Harold wrote:
> I've implemented the getSerializedForm() methods in Element and
> Document. The code is at
[...]
> 
> http://metalab.unc.edu/xml/jdom/Document.java
> http://metalab.unc.edu/xml/jdom/Element.java
> 
> Neither the code nor the output is particularly elegant. I know we plan
> to move this functionality into XMLOutputter or some similar class soon,
> so I didn't want to go overboard with it; and indeed I'm not sure we
> should check this into the main tree since it would mostly encourage
> using an API that will change soon. However, I did want to finish it up
> as a way to get started on the more permanent API.
> 
> I think what I'm going to do now is spend a little time thinking about
> what the API for node-by-node serialization should look like. I'm
> leaning toward making this a different class than XMLOutputter, and to
> implement it as a series of static methods that only return strings.
> Some methods might use an XMLOutputter internally though. Or is that
> backwards?  Certainly there's a lot of code that needs to be shared
> between XMLSerializer and XMLOutputter, if indeed they aren't the same
> thing. However, I would very much like to avoid the encoding hassles
> that plague XMLOutputter in XMLSerializer. 
> 
> 
> -- 
> +-----------------------+------------------------+-------------------+
> | Elliotte Rusty Harold | elharo at metalab.unc.edu | Writer/Programmer |
> +-----------------------+------------------------+-------------------+ 
> |               Java I/O (O'Reilly & Associates, 1999)               |
> |            http://metalab.unc.edu/javafaq/books/javaio/            |
> |   http://www.amazon.com/exec/obidos/ISBN=1565924851/cafeaulaitA/   |
> +----------------------------------+---------------------------------+
> |  Read Cafe au Lait for Java News:  http://metalab.unc.edu/javafaq/ | 
> |  Read Cafe con Leche for XML News: http://metalab.unc.edu/xml/     |
> +----------------------------------+---------------------------------+
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com

-- 
Alex Chaffee                       mailto:alex at jguru.com
jGuru - Java News and FAQs         http://www.jguru.com/alex/
Creator of Gamelan                 http://www.gamelan.com/
Founder of Purple Technology       http://www.purpletech.com/
Curator of Stinky Art Collective   http://www.stinky.com/