[Fwd: [jdom-interest] getSerializedForm() [eg]]

[Jason Hunter]

In all the detach() debate this thread seems to have been ignored.  I
think it's important we decide something.  Here's the main questions:

Do we remove getSerializedForm() entirely or do we keep it returning a
"default" XML representation of the object?  In implementing the removal
I've had second thoughts about the removal.  I'm tempted to keep gSF()
to make things easier on the user.  The only downside is that it ties
the elements to the XMLOutputter but in implementing the removal I noted
we already have that dependency now for toString().

Our options:

1. Remove getSerializedForm() and have toString() output something
non-XML like "[ProcessingInstruction: target: pi data: data]"
* No dependencies in org.jdom on org.jdom.output
* But ugly toString()
* Ugly new XMLOutputter.outputString(elt) instead of
elt.getSerializedForm()

2. Keep getSerializedForm() and have toString() output status quo like
"[ProcessingInstruction: <?pi data?>]"
* Has dependencies in org.jdom on org.jdom.output
* Nice toString()
* Convenient getSerializedForm() call

3. Status quo of no gSF() with toString() as in #2
* Has package dependencies
* Nice toString()
* No convenient gSF()

I tend to like #2 because conveniencing the user is more important than
keeping org.jdom oblivious to org.jdom.output.  As a parallel, java.lang
depends on other core packages including java.io.  What's wrong with
org.jdom knowing about org.jdom.output for toString() and
getSerializedForm()?

-jh-
-------------- next part --------------
An embedded message was scrubbed...
From: Jason Hunter <jhunter at collab.net>
Subject: [jdom-interest] getSerializedForm() [eg]
Date: Fri, 20 Apr 2001 01:09:29 -0700
Size: 2562
Url: http://jdom.org/pipermail/jdom-interest/attachments/20010424/97853967/attachment.eml