Java coding is dangerously close to being off-topic...
I used to steer very clear of anonymous classes but I'm tending to use them
rather more for callbacks than I used to. The big disadvantage of course is
that the code isn't reusable.
Your code raises the question of whose resposibility it is to call
setSystemId() on the returned Source object. I don't think the spec makes it
clear.
Michael Kay
http://www.saxonica.com/
-----Original Message-----
From: Robert Koberg [mailto:rob(_at_)koberg(_dot_)com]
Sent: 29 February 2008 22:02
To: xsl-list
Subject: [xsl] java-xsl - functional(?) URIResolver
Hi,
Maybe some of you already do this, but I am finding anonymous
URIResolvers incredibly useful. You can use private method
variables, instance variables, instance methods, etc from the
same class that you call the transform. In the past I usually
passed objects to the URIResolver constructor, but this seems
much better (example below).
Anybody see any problems with this approach?
Transformer transformer = xslTemplates.newTransformer();
transformer.setURIResolver(new URIResolver() {
public Source resolve(String href, String base) {
if ("page-data".equals(href)) {
return new StreamSource(
new StringReader(
resolvePageData(handler)));
} else if ("message-keys".equals(href)) {
return new StreamSource(
new StringReader(
resolveMessageKeys(handler)));
} else {
return new StreamSource(
new StringReader(
resolveNotHandled(href)));
}
}
});
best,
-Rob
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail:
<mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--