[jdom-interest] SAXOutputter

[Yuri de Wit]

Hi Jason, 

Thanks for the response and sorry for sending a reply a "year" later!

The use case I am dealing with requires me to use functionality already
implemented in the SAXOutputter and not to change and/or extend its
functionality. If my intention was to extend the behavior of SAXOutputter, I
am with you and your point is well taken!

My data is a tree-like structure where its top levels are not JDOM, but my
own node classes. From the 3rd level down, this tree contains JDOM elements.
I need to generate SAX events for this mixed tree (non-JDOM and JDOM
elements) as if it was one  XML document. In order to do that, I wrote a
class that generates SAX events for the first three levels of the tree and
would like to use the SAXOutputter to generate the events for the rest of
the tree. 

Currently, SAXOutputter exposes only one public method to generate SAX
events and this method expects a Document, but I only have JDOM Elements in
my tree. When generating SAX events for the tree and I get to the 3rd level
I could create a dummy Document, set the element in question as the root
element, and continue generating SAX events, but then I would be generating
a second startDocument and endDocument.

My "request for enhancement" is to expose at least another public method in
SAXOutputter so that I can generate SAX events for one element (not a
Document) and that it will NOT generate the startDocument and endDocument
events.

public class SAXOutputter
{
	...
	
    public void output(Element element) throws JDOMException {
		....
	}

	...
}

Yuri

-----Original Message-----
From: Jason Hunter [mailto:jhunter at servlets.com]
Sent: Tuesday, September 24, 2002 15:58
To: Yuri de Wit
Cc: 'jdom-interest at jdom.org'
Subject: Re: [jdom-interest] SAXOutputter


Watch out, Jason's getting philosophical...

We've been slowly but steadily increasing the number of protected fields
in the input/output classes to the point where nearly the entire
internals are exposed.  It's one of the things I dislike most about
JDOM.  I think a better approach is to allow pluggable logical
components to handle specific tasks.  It's similar to the factory model
where we plug-in a factory to handle element creation, but used more
extensively.  It's difficult, of course, because everyone has a need for
something else, and even the current factory model doesn't solve all use
cases.  

Our original vision was for people to write many builders.  Just turns
out writing builders is really hard and so everyone wants to leverage
SAXBuilder but not actually copy/paste the code, thus exposing internals
through protected methods and variables, but that of course means that
the flexibility of SAXBuilder to alter its internals is effectively
non-existent.

I think if we're going to push to get JDOM to be a JSR standard, then
there has to be a standard builder (having very few if any protected
fields using plug-ins instead) with an optional probably non-standard
builder that's more a free-for-all as a starter for writing your own
builders.

-jh-

> Yuri de Wit wrote:
> 
> Currently, the element() method on SAXOutputter has private
> visibility. Could we relax it to at least protected for the next
> release?
> I have a data model with JDOM Elements mixed with homegrown data
> structures and would like to reuse the SAXOuttputer functionality for
> the JDOM elements but SAXOutputter only has an output(Document doc) as
> public.
> 
> Thanks,
> 
> Yuri