[jdom-interest] AleXMLOutputter

[tsasala at hifusion.com]

	I'm a little confused here.  What's the serious problem with 
having toString like methods on all the objects?  It would output the 
basic information in a generic way, thus, keeping the API simple and
very useful.  Additional classes can be formulated to handle a wide
range of tasks that toString can't (or won't).  Much like the 
proposition of of a Format class.

	-Tom

Andrzej Bialecki wrote:
> 
> Hello,
> 
> On Sat, 15 Jul 2000, Elliotte Rusty Harold wrote:
> 
> > At 7:45 AM -0700 7/14/00, Alex Chaffee wrote:
> 
> > >I rewrote XMLOutputter to have public methods for serializing nodes
> > >other than document.  Patch is at the end of this email.  I don't want
> > >to step on Rusty's toes here, but the fact is, my code works, more or
> > >less, so an argument could be made for checking it into the main code
> > >base pending further developments from Rusty's camp.
> 
> > The issue I see with these is that the API is far more complex than
> > it needs to be. This is not sufficient to replace
> > getSerializedForm().  Given an Element e (or a Comment c, or a
> > Document d) calling getSerializedForm() is easy. Just
> >
> > String s = e.getSerializedForm();
> 
> I've been lurking here for some time, but not too long, so I'm not sure if
> this topic was discussed before...
> 
> Anyway: why Elements, PIs, DocType etc.. don't extend the same basic
> class? Or implement common interface that extends Serializable? IMHO it's
> easier for developer to just throw whatever he has on the plate to the
> XMLOutputter without having to know which particular method to use for
> this particular node type. I think this would simplify API.
> 
> The reason for this question is that in my application I have to serialize
> parts of documents, starting from specific node (not from the root), and
> then store split parts (adding some decoration like docType) into
> different locations. Tt would be nice to have possibility to supply any
> document fragment, not only the root element, to XMLOutputter and receive
> it in serialized form.
> 
> > The big issue is how to configure the formatting performed by
> > XMLOutputter.getSerializedForm(). We could:
> 
> I don't mind supplying additional object specifying dozens
> of serialization parameters. This would buy me extra flexibility of
> having different serialization parameters for different document
> fragments (e.g. pretty formatting for parts likely to be read by
> humans, condensed spaghetti for parts to be stored in the DB).
> 
> I'd vote for OutputFormat class, if it matters :-)
> 
> Andrzej Bialecki
> 
> //  <abial at webgiro.com> WebGiro AB, Sweden (http://www.webgiro.com)
> // -------------------------------------------------------------------
> // ------ FreeBSD: The Power to Serve. http://www.freebsd.org --------
> // --- Small & Embedded FreeBSD: http://www.freebsd.org/~picobsd/ ----
> 
> _______________________________________________
> To control your jdom-interest membership:
> http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhost.com