[jdom-commits] CVS update: jdom/src/java/org/jdom/output
jhunter at cvs.jdom.org
jhunter at cvs.jdom.org
Fri Apr 20 00:30:35 PDT 2001
Date: Friday April 20, 2001 @ 8:30
Author: jhunter
Update of /home/cvspublic/jdom/src/java/org/jdom/output
In directory www.nmemonix.com:/tmp/cvs-serv18628/src/java/org/jdom/output
Modified Files:
XMLOutputter.java
Log Message:
Deprecated all the various getSerializedForm() methods and moved the logic
(when needed) into XMLOutputter. To help users, I also added directions
in toString() that for an XML string representation of the component
you can use XMLOutputter.outputString(). This was discussed last week.
I had to do something with the toString() methods, many of which used to
call getSerializedForm() as part of their output. For example:
[Comment: <!-- comment -->]
[ProcessingInstruction: <?pi data?>]
[CDATA: <![CDATA[hello]]>]
[Element: <servlet/>]
[DocType: <!DOCTYPE a PUBLIC "b" "c">]
[Document: No DOCTYPE declaration, Root is [Element: <web-app/>]]
So what I did for now is change those toString() methods to call
XMLOutputter.outputString(). I'm not sure how much I like org.jdom
depending on org.jdom.output though.
Assuming we need that dependency to have a nice toString(), I'm wondering
what it would hurt to keep the getSerializedForm() methods and implement
them to call XMLOutputter methods. For Element/Document where output can
be long and heavily customized, we simply output using the default
XMLOutputter and instruct the programmer to call outputString() on
XMLOutputter if they want more control.
Comments welcome on jdom-interest.
-jh-
===================================================================
File: no file XMLOutputter.java Status: Needs Checkout
Working revision: 1.43 Fri Apr 20 07:30:35 2001
Repository revision: 1.43 /home/cvspublic/jdom/src/java/org/jdom/output/XMLOutputter.java,v
Existing Tags:
start (revision: 1.1.1.1)
jdom (branch: 1.1.1)
More information about the jdom-commits
mailing list