[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:
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.


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:
	jdom                     	(branch: 1.1.1)

More information about the jdom-commits mailing list