[jdom-interest] SAXOutputter

[Jason Hunter]

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