edoardo at knowledgeview.co.uk
Wed Apr 4 04:24:55 PDT 2001
ah - sorry, Laurent!
instead of thinking why the Result interface is so small, that can't be used
I naively thought XSLT processors could work with an abstraction of a
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
> 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?
> 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
More information about the jdom-interest