[jdom-interest] org.jdom.contrib.transform.JDomResult

[Edoardo Comar]

ah - sorry, Laurent!
instead of thinking why the Result interface is so small, that can't be used
practically,
I naively thought XSLT processors could work with an abstraction of a
Result.

Edo

I remember once I was working with a product (a java report writer) whose
API included an interface, but it failed with any its implementation that
was not one of the prepackaged ones.

> -----Original Message-----
> From: Laurent Bihanic [mailto:laurent.bihanic at atosorigin.com]
> Sent: 04 April 2001 12:13
> To: Edoardo Comar
> Cc: jdom-interest at jdom.org
> Subject: Re: [jdom-interest] org.jdom.contrib.transform.JDomResult
>
>
>
> Hi,
>
> Most (if not all) XSLT processors will recognize a SAXResult and
> know how to
> use it.  What can an XSLT processor do with an unknown subclass
> of Result?
> The only two methods Result defines are getSystemId() and setSystemId().
>
> With your class, how will the XSLT processor get access to the
> wrapped SAXResult?
>
> Laurent
>
> Edoardo Comar wrote:
>
> > Hi I was looking at JDomResult and wandered why it extends SAXResult,
> >
> > and has to override its setters so not to change its internals.
> >
> >
> >
> > I'd change it such that :
> >
> > JDomResult implements Result
> > *wraps* a privately held SAXResult
> > adds its raison-d'etre, the getDocument()  method
> >
> > Edo
> >
>
>