[jdom-interest] AleXMLOutputter

Elliotte Rusty Harold elharo at metalab.unc.edu
Sat Jul 15 06:44:37 PDT 2000

At 7:45 AM -0700 7/14/00, Alex Chaffee wrote:
>While Rusty is busy refactoring XMLOutputter in order to cleanly deal
>with encoding issues, I've gone ahead and solved the encoding issues
>by ignoring them. :-)
>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.

>- methods printComment, printProcessingInstruction, printDeclaration,
>printDocType, printElement, printEntity, printNamespace,
>printAttributes are now public

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();

What you're proposing replacing that with is

StringWriter out = new StringWriter();
XMLOutputter outputter = new XMLOutputter();
outputter.printElement(e, out);
String s = out.toString();

That's a lot more complicated and not at all obvious.  What I'm 
proposing is something more like this:

String s = XMLOutputter.getSerializedForm(e);

We replace one method call with one method call. It's still not quite 
as obvious as e.getSerializedForm() but it's as close as we can get 
in a different class.

I suspect we need your API anyway. The API for writing something onto 
a stream or a writer has a certain necessary complexity. But that 
need not interfere with providing a simple API for simple things.

The big issue is how to configure the formatting performed by 
XMLOutputter.getSerializedForm(). We could:

*  provide a lot of static setDefaultIndent() methods and their ilk 
(Yuck, just a lot more detritus in the class. Some of the java.net 
classes do this and it's really ugly IMHO)

* make getSerializedForm() an instance method (thereby requiring 
client programmers to call an extra constructor just to get a string 
representation of the object, and making this a more complicated 
operation than it is now)

* Provide a static default XMLOutputter in the XMLOutputter class 
preinitialized that users can call and that the toString() methods 
can call (not out of the question) without having to construct it 

* Separate formatting options into a separate OutputFormat class, 
perhaps even a public inner class like  XMLOutputter.Format like 
Xerces does and like Jason tells me Enhydra does. Then we'd add 
overloaded methods like this:

public static String getSerializedForm(Element e, OutputFormat options)

You (Alex) really don't seem to like this option, but it does add one 
more advantage: we could very easily share formatting between 
different outputters. For instance, if I've got a server writing to 
ten streams at once with then XMLOutputters, they could all use the 
same set of formatting options. If I added an eleventh stream I could 
easily clone off another copy and set up my default options very 
easily and quickly.

* Use a static XMLSerializer class with a lot of static methods to 
perform these  basic operations. However it would depend on a 
private, static instance of XMLOutputter to do the formatting. This 
keeps the API for writing onto a stream and for producing strings 
separate, but it reverses the logic sop that the string producer 
depends on the outputter rather than the other way around. We could 
then easily provide all the set formatting methods we wanted. 
Disadvantage: somewhat thread unsafe and hard to make thread safe 
unless we synchronize inside the class.

| Elliotte Rusty Harold | elharo at metalab.unc.edu | Writer/Programmer |
|                  The XML Bible (IDG Books, 1999)                   |
|              http://metalab.unc.edu/xml/books/bible/               |
|   http://www.amazon.com/exec/obidos/ISBN=0764532367/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/     |

More information about the jdom-interest mailing list