If such a filtering was to exist in the core, I'd prefer to rely on a
generic java.io.FilterInputStream filter than on a new interface
tagerting only lines. But that remains a good idea. Fell free to open an
enhancement issue so that it gets a chance not to be forgotten, and to
submit a patch if you implement it.
Claude
On 2011-03-23 14:53, Rich Wagner wrote:
First of all, thanks for all the responses: they've been helpful.
Here's an idea to chew on: Instead of having Velocity users augment their resource loaders, whether the
"File..." one or the "Webapp..." one, what about providing a way to expose a line
filtering option at a different level? To be specific, imagine 7.1 (say) supported a new configuration key:
"template.line.filtering.class". When not set, Velocity would behave as it does today: no
filtering. But if that's configured with the fully qualified class name for a class that implements this
interface:
public interface ILineFilter {
/**
* Optionally changes the given line from a Template source,
* returning the filtered result. If null is returned, the
* filter is expressing a desire for the entire line to be
* filtered away.
* @param line the line to (potentially) filter; does not
* end with line termination character(s) like
* '\n' or '\r'.
*/
String filterLine(String line);
}
...then the Velocity code that interacts with any and all loaders would know to
wrap the InputStream produced by the applicable loader with a filtering
InputStream that applies the user-supplied filter to each Template source line.
Something like this:
templatesInputStream = { stream produced by resource loader }
if ( "template.line.filtering.class" is set by user ) {
ILineFilter lineFilter = { "newInstance" of user's configured class }
wrappedStream = new LineFilteringInputStream (templatesInputStream,
lineFilter);
templatesInputStream = wrappedStream;
}
... created the Template using "templatesInputStream" ...
The benefit is that users don't have to configure their (one or more) resource
loaders: the filtering is done in one place. Plus the amount of code the user
needs to write is smaller, and it's much more to the point: the user doesn't
need to get involved with resource loader implementation details, nor line
reading/buffering, etc...
Just a suggestion...
Thanks,
Rich
________________________________
Kiva.org - Loans That Change Lives
----------------------------------------
Subject: Re: Directive indenting ?
From: [email protected]
Date: Wed, 23 Mar 2011 14:04:52 +0100
To: [email protected]
OK, I'll try the FileResourceLoader as it failed at runtime with the
WebappResourceLoader.
I already change the code to use StringBuilder.
I'll share it with pleasure !
Let me just validate it work for me with the FileResourceLoader.
On 23 mars 2011, at 14:01, Claude Brisson wrote:
As noted on the wiki page, this custom resource loader extends
WebappResourceLoader but you can do exactly the same while extending
FileResourceLoader.
If you do so, be sure to share it! Also, the code could probably be optimized a
bit (for instance by using a StringBuilder instead of a String for its inner
buffer).
Claude
On 2011-03-23 10:47, Jean-Baptiste BRIAUD -- Novlog wrote:
It doesn't compile :
the WebappResourceLoader class is not found.
I guess it is in the velocity-tool.jar extra lib ... I'll try, I have several
emergency in parallel :-)
If my guess is correct, I'll just have to add a new dependency on my project.
I'll let you know.
On 22 mars 2011, at 17:20, Claude Brisson wrote:
It's a very straightforward input filter that uses the common resource loading
API - it should work well with 1.7.
It's the filter itself that should be considered beta.
Claude
On 2011-03-22 14:33, Jean-Baptiste BRIAUD -- Novlog wrote:
Does it work with current 1.7 (latest stable) version or should I migrate to V2
beta ?
If yes, is that beta version stable enough ?
On 22 mars 2011, at 11:41, Jean-Baptiste BRIAUD -- Novlog wrote:
Thanks for the pointer ! For years, I was thinking it was not possible.
On 21 mars 2011, at 20:52, Claude Brisson wrote:
Yet, you can check a custom resource loader available on the wiki that does
precisely this:
http://wiki.apache.org/velocity/StructuredGlobbingResourceLoader
Claude
On 2011-03-21 19:50, Sergiu Dumitriu wrote:
On 03/21/2011 07:04 PM, Rich Wagner wrote:
Sorry in advance if this is a FAQ whose answer I haven't found...
Instead of writing:
#foreach( $container in $Containers )
#if( $container.prop("Generate") )
...stuff...
#end
#end
I'd like to indent the "#if" and its "#end", for the sake of better readability:
#foreach( $container in $Containers )
#if( $container.prop("Generate") )
...stuff...
#end
#end
But then I find the spaces before the "#if" and its matching "#end" show up in
the output, which I don't want to happen.
To get around this, I've implemented a somewhat hack-ish Template preprocesser: my
resource loader wraps a template's stream inside my own stream implementation which
filters template lines. That is, if a line starts with "#blah", the initial
spaces are trimmed off.
That works, and isn't all that intrusive. But if "off-the-shelf" Velocity
already provides an easier way to accomplish the same thing, I'd prefer that...
No, there's no similar feature directly in Velocity yet.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
