[jdom-interest] AleXMLOutputter

Alex Chaffee guru at edamame.stinky.com
Tue Jul 18 21:59:18 PDT 2000

On Mon, Jul 17, 2000 at 04:20:15PM +0200, Andrzej Bialecki wrote:
> On Mon, 17 Jul 2000 tsasala at hifusion.com wrote:
> > 
> > 	I'm a little confused here.  What's the serious problem with 
> > having toString like methods on all the objects?  It would output the 

OK, as for the "why nots..."

Why not toString()?

	Because toString is supposed to print a short debugging
message, not suitable for display to a user. For JDOM, it should (?)
print the element name and possibly a count of its contents, in a
concise string. XML (as output format) is many things, but it is not

	Furthermore, there is no one XML format that fits all
needs. Sometimes you want line breaks, sometimes you want indents,
sometimes you want comments, sometimes you want whitespace preserved,
sometimes you don't.  Variation -> parameterization -> a separate
outputter/formatter class.  Instead of e.toSerializedForm(), use new
XMLOutputter(true, false, "\n").formatElement(e), or something like

	Naturally, we could define "e.toSerializedForm()" to make a
new XMLOutputter with default parameters, but I recommend against
that, since the definition of XMLOutputter and its defaults could

Why not Serializable?

	Because the name "Serializable" has been taken already, by the
java.io package, for a binary format.

	Furthermore, see above paragraph beginning "Furthermore."

Why not use XMLOutputter instead of having a separate XMLFormat (or
vice versa)?

	Because arcane issues surrounding character encodings may (or
may not) require refactoring the clean, nice string formatting logic
away from the nasty, brutish encoding logic.

	Personally, I feel this is probably unnecessary, or if it is,
it shuld happen behind the interface, as an implementation detail.

> > > > 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 agree. I didn't take the time to make simple method signatures for
all node types.  

> > > Anyway: why Elements, PIs, DocType etc.. don't extend the same basic
> > > class?

I agree. There should be a common Node interface/abstract class; we
could easily write a print(Node n) method in the XMLOutputter that
would work for all Nodes.

> > > > 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).

Gak! Please read my earlier message explaining that OOP means that the
object *is* its own options class. There's no need to make a separate
redundant options object. Instance variables/ properties are adequate
for the purposes of configuring an object.

E.g. XMLOutputter outHuman = new XMLOutputter();

     XMLOutputter outDB = new XMLOutputt();

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/

More information about the jdom-interest mailing list