Adds a TemplateTransformModel to FreeMarker.
The idea is that it's similar to TemplateMethodModel, but operates over template content, rather than variables. Can be use to re-implement <compress> functionality, the HTML transforms used by the JSP taglib, etc.
At the moment the implementation takes two arguments, a Reader and a PrintWriter. As it happens, for all the test cases I've written, the first thing I do is to buffer the Reader with a char array, and then read from that.
Question: would it be better to implement a SAX-style interface, where the method takes a character buffer, an offset, and a length, and returns a String? Possible issues with this:
* Possibly loss of generality: some implementations may prefer a Reader object, particularly if filtering through an external package such as JDom
* At the beginning and end of a parse, similar to SAX, call beginTransform and endTransform methods respectively, to allow the transformation to initialise and clean up.
* Similar to SAX, implementing classes may need to save more state information inside the object.
Have to mail the mailing list with opinions...
Oh yeah, the syntax:
(content to be transformed, including any/all of the usual FreeMarker syntax)
As an unexpected, yet fortuitous side-effect, TemplateTransformModels co-operate rather well when wrapped inside a TemplateMethodModel. This technique can be used to select which TransformModel to use, based on a parameter passed to the MethodModel. Also, a similar technique can be used to pass parameters to the TransformModel, using MethodModel as an adapter.
The syntax in these cases would be:
<transform example.MethodReturningATransformModel( argument1, argument2, etc )>
(content to be transformed)