[jdom-interest] making SAXOutputter extensible

[PJ Fanning]

Thanks for the advice. What I have done is to create a new class locally
that reuses the shipped source (as Jason Hunter suggested). I took this
approach because I want to modify the iterations through the content lists
so that the list items are removed. Once a document is 'output', it will
then have no content. I don't think that encapsulation would solve my
problem.

-----Original Message-----
From: William Krick [mailto:wkrick at eio-online.com]
Sent: 06 January 2004 16:47
To: jdom-interest at jdom.org; PJ Fanning
Subject: RE: [jdom-interest] making SAXOutputter extensible


You can always use encapsulation instead of inheritance.  Create you own
class that includes an instance of the SAXOutputter as a member.  Then you
write a bunch of trivial wethods for your class that call the same named
methods of the instance, passing the parameters and returning the results.
It's essentially a fancy wrapper.  You can then add any new functionality
you want.  It's not always the most efficient implementation but it usually
works.  The main problem is when you have methods that take a SAXOutputter
as a parameter.  As your new class isn't extended from SAXOutputter, it
won't be compatible with the method signature.  This sort of problem makes a
really good case for more widespread use of Interfaces.

If encapsulation isn't an option, you can always take the source for
SAXOutputter and modify it to create your own class (using a different name,
of course) and submit it.  If it turns out to be useful to other people,
maybe it will be added to the JDOM package.

...
Krick

> -----Original Message-----
> From: jdom-interest-admin at jdom.org
> [mailto:jdom-interest-admin at jdom.org]On Behalf Of Jason Hunter
> Sent: Tuesday, January 06, 2004 3:49 AM
> To: PJ Fanning
> Cc: 'jdom-interest at jdom.org'
> Subject: Re: [jdom-interest] making SAXOutputter extensible
>
>
> Any time you make internal fields of a class like SAXOutputter protected
> or public, that's a promise not to change their names or behavior in the
> future lest we break people's code.  That eliminates the benefits of
> encapsulation and is a larger promise than I think we should sign up
> for.  The real solution then is for you to just take advantage of the
> source that's distributed and make the changes yourself.  That way at
> least you understand that your code depending on SAXOutputter internals
> may break in future releases.
>
> -jh-
>
> PJ Fanning wrote:
>
> > Hi,
> > I've got a small enhancement request.
> > I'd like to produce a subclass of SAXOutputter that destroys
> the document as
> > it outputs it, in order to conserve memory. The current
> codebase does not
> > allow you to extend this class. Specifically, most of the members and
> > methods are private. If they were marked as protected and the
> NamespaceStack
> > class marked as public, I would be able to achieve what I'm
> looking to do.
> > If there are no objections, I could forward modified versions
> of these two
> > classes to the list.
> > _______________________________________________
> > To control your jdom-interest membership:
> >
> http://lists.denveronline.net/mailman/options/jdom-interest/yourad
dr at yourhost.com
>

_______________________________________________
To control your jdom-interest membership:
http://lists.denveronline.net/mailman/options/jdom-interest/youraddr@yourhos
t.com