[jdom-interest] Ampersand question

[Elliotte Rusty Harold]

At 12:40 AM -0700 7/13/00, Alex Chaffee wrote:
>> >         Shouldn't the getSerializedForm output & instead
>> > of &?  The outputter class does special processing to output
>> > <, >, & as their escaped equivalents.  Am I missing something
>> > here?
>>
>> Yes, but there are 3 versions of that method right now (beta4, CVS,
>> Elliotte's web page) so which one has the problem?  :-)
>
>Any thoughts on my suggestion to remove getSerializedForm()
>altogether?  This would force people to use an XMLOutputter, with
>well-defined behavior, or roll their own.  Furthermore it would
>improve the separation between data and view.  "Serialized form" is a
>view and has no real business being in the data object.
>
> - A

I worked on it some yesterday. I'll try to finish it up tomorrow. My 
current thought is to create a new class called 
org.jdom.output.XMLSerializer which has a whole bunch of serialize 
methods that take JDOM objects and return strings; e.g.

public String serialize(Comment c)
public String serialize(Element e)
public String serialize(Document d)

Then I'd rewrite the XMLOutputter class to depend on these serialize 
methods. XMLOutputter's primary job would become interfacing with 
streams and writers and handling encoding issues. XMLSerializer won't 
have any encoding problems because it just returns strings. If we 
still want a getSerializedForm() method in the individual classes 
like Comment and Element, then they can simply call the serialize 
method in XMLSerializer. All code to serialize will be localized in 
this one class, which I think is a good thing.

What I'm struggling with now is whether I can get away with making 
all the methods static; e.g.

public static String serialize(Comment c)
public static String serialize(Element e)
public static String serialize(Document d)

After all each method just takes an object as an argument, 
manipulates that object, and returns a string. There's no real 
interaction with any state in the class. This is a perfect place for 
a static method.

The issue is the configuring of the serializer. Ideally, I'd like to 
provide the following user settable options:

indent string
line separator string
maximum line length

and possibly others such as

single or double quotes for attribute values
empty element tag syntax or not

I suspect people will think of more things besides.  These are a few 
too many to comfortably pass into each call to serialize(Document d) 
or serialize(Element e). I'm thinking about adding a third class that 
just holds the configuration information so that this could be passed 
as an argument to the various serialize methods, sort of like a 
watered down version of the OutputFormat class from Xerces in 
org.apache.xml.serialize. The alternative is to allow these to be set 
on an XMLSerializer object through constructors and setter methods. 
However, that would prevent me from using static serialize methods 
and make the defaults a little harder to set up. Ideally, I'd like 
users to be able to pass their object to one method and get a String 
back with a minimum of effort. However, I do want to allow them the 
option of changing the default formatting.

+-----------------------+------------------------+-------------------+
| 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/     |
+----------------------------------+---------------------------------+