[jdom-interest] getSerializedForm() [eg]

[Jason Hunter]

> toString is mostly for debugging.  The implementation should represent all
> useful internal state, not just what happens to have an XML form.
> 
> The [Foo: bar=baz] form is fairly typical.  Subclassers are encouraged to
> override it in order to display any additional state they add.

I started rewriting toString() impls to behave this way but then I began
to think the XML representation is more naturally readable for things. 
Compare:

[DocType: elementName="a", publicID="b", systemID="c"]
[Comment: text=" comment "]

vs

[DocType: <!DOCTYPE a PUBLIC "b" "c">]
[Comment: <!-- comment -->]

When I see the XML rep in an OptimizeIt window I can parse it naturally
and at a glance.  With the generic representation, I would have to work
at it.  I could learn to read it, but it'd be less obvious to newbies.

Note that Element and such would work like this:

[Element: <servlet/>] 

No matter what content is within Element.  It's not meant to call
getSF() but just provide a short XML-familiar way to show that it's an
Element.

Note, with the non-XML we could theoretically add more than the XML
offers, but it gets tricky.  Like Element.toString() can print its
parent, but the problem is that its parent's toString() would also print
its parent, and so on.  It's an explosion of info if you try to print
the parentage.  That added extra appeal to the XML rep.

Have to think about the subclass implications.  At first blush, they can
override toString() to do as they like.  Non-radical subclasses will
take advantage of the default toString() behavior.  Radical subclasses
(like using a database-backed impl) will probably ignore the provided
protected variables anyway to using a=b won't help them much and they
won't call super.toString() anyway.

-jh-