[jdom-interest] Ampersand question

[Alex Chaffee]

Rusty -

Your efforts are admirable!  I'm glad you're thinking and hacking on
this.

However, the architecture is misguided.  We do not need a separate
class called XMLSerializer.  We already have one that does almost
everything we want, called XMLOutputter.

Here's my vision, in a nutshell:

	XMLOutputter has methods to output a

	[Document or Element or Comment or etc.] 

	to a

	[Stream or String] 

	applying options on

	[whitespace and linefeeds and line wrap and encoding and other
	output options]

The output options will be set as instance properties.
e.g. setLineSeparator("\r")

That will suffice for *all* needs.

If you disagree, please come up with a specific use case where you
need a separate Serializer class and I will demolish it :-)


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

No, since as you mentioned that precludes setting options. statics are
very dangerous and usually the wrong idea, since you have to pass all
state in as parameters.


> 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

Congratulations, you just reinvented object-oriented programming.

This "third class" is called "this", and it is passed in as an
implicit argument to each member function of an object instance.


To belabor the point: an object is *just* a pointer to a set of
options (instance data) that gets passed in to a set of functions
(methods) so that the programmer doesn't have to maintain structs and
pass pointers around.  That's it!  There's no harm in making
XMLOutputter contain lots of properties -- that's what OOP is for.
And there's no need to make a constructor for each permutation of
option settings.  Just provide two or three for the most common cases
and that's it.


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