[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
first
* 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