Refactor AbstractXsltView to use Source instead of DOM

[msqr]

I've been working with the AbstractXsltView class along with using JAXB for rendering XML objects. I would have liked to extend the AbstractXsltView class and make a few simple changes to use a JAXBSource (implementation of javax.xml.transform.Source) for the resulting XSLT transform, instead of redering a DOM from JAXB and then passing the DOM back to AbstractXsltView.

I ran into a couple of road blocks with the AbstractXsltView implementation, however, that prevent me from extending the class. First, the renderMergedOutputModel() method is declared final. This prevents me from using anything other than a DOM source if I extend AbstractXsltView. A simple change would be to just remove the final declaration to allow extending classes to take advantage of the XSLT template caching and transform code already in AbstractXsltView.

Then I thought perhaps AbstractXsltView could be more useful if instead of requiring a DOM node, to require just an XSLT Source object, so instead of

protected abstract Node createDomNode(
		Map model, String root, HttpServletRequest request, HttpServletResponse response)
		throws Exception;

we'd have this:

protected abstract Source createXsltSource(
		Map model, String root, HttpServletRequest request, HttpServletResponse response)
		throws Exception;

this doesn't change extending classes too much, as to return a Source from a DOM object you simply use

return new DOMSource(dom)

Then AbstractXsltView could make some minor tweaks to it's doTransform() methods to pass this Source object instead of a DOM object.

I have an implementation of AbstractXsltView incorporating these changes that I can post if anyone is interested... I'm interested if anyone else has thoughts on this matter.

[davison]

this doesn't change extending classes too much, as to return a Source from a DOM object you simply use

return new DOMSource(dom)

But it does make the class non-backward compatible for people already using it. It seems like the method could be added as an option however so that you can choose which one to override/implement with the AbstractXsltView class taking account of this.

I have an implementation of AbstractXsltView incorporating these changes that I can post if anyone is interested... I'm interested if anyone else has thoughts on this matter.

If you create an issue in JIRA and attach a diff (patch) file for your changes to this class I'll take a look at it for you.

Regards,

[msqr]

Done:

http://opensource.atlassian.com/proj...browse/SPR-730

You are absolutely correct about breaking compatibility... but I thought keeping the class simple might be desirable, too