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]
