[jira] Commented: (VELTOOLS-63) webapp.resource.loader.extension property that gives a mandatory extension to add to resource names

["Claude Brisson (JIRA)" <ve...@apache.org>]

    [ http://issues.apache.org/jira/browse/VELTOOLS-63?page=comments#action_12436042 ] 
            
Claude Brisson commented on VELTOOLS-63:
----------------------------------------

Ok, ok, ok.
I heard your thoughts, guys.
Wrong method. Bad. Ugly. Shame on me. All the resources are mapped to the velocity view servlet, and the log is fulled of useless and verbose ResourceNotFoundException.
In a nutshell, forget it.

So, let me rephrase both the problem and propose another, much nicer, solution, that I'd like to share.

The problem
----

You want to be able to dynamically and progressively transform a static site into a dynamic site. Typically, it happens when a designer gives to the coder a static model of a site where the links between pages are functionnal but the data shown inside are frozen.

Storing the regular files and the templates in different directory trees is feasable but really painful for the coder.

Thus, we need to store the templates and the regular files in the same directory tree, distinguishing templates with a supplementary ".vtl" extension, but without breaking former URLs (yes, I know about "perl -pi -e s///g" but... how to say.... ).

The solution:
----

The only clean solution I found is to implement a TemplateNameFilter that adds ".vtl" on the fly to template URIs. The only drawback is that the filter must build and cache the list of all the .vtl files in the webapp. So I've set up cache resets, either periodically or manually triggered by http.

I'm gonna put it both in this bugreport and in the contributed code section of the wiki. Let me know what you others think about it.

Here is a paste of its javadoc section:

--------------------------------------
This class is a forwarding filter which allows to hide ".vtl" from resource URLs. It works by building a cache of all template names in the webapp, and adding

The purpose of this feature is to allow URLs to be independant of the status of the resource: regular file or template file, allowing this status to transparently change over time. You can store all resources in the same directory tree, templates having an additional ".vtl" like in "foo.html.vtl" or "bar.js.vtl".

In development mode, you can choose either to reset the cache periodically, or manually with the "reset-cache" URI, or both.

Initialization parameters:

    * template-extension: the targeted template extension (default: ".vtl").
    * reset-method: "periodic" or "manual" or "both" or "none" (default: "none").
    * reset-uri: the rest uri, for manual resets (default: "/reset-cache").
    * reset-period: the period, in seconds, between two resets, for periodic resets (default: 120s).
------------------------------------


> webapp.resource.loader.extension property that gives a mandatory extension to add to resource names
> ---------------------------------------------------------------------------------------------------
>
>                 Key: VELTOOLS-63
>                 URL: http://issues.apache.org/jira/browse/VELTOOLS-63
>             Project: VelocityTools
>          Issue Type: New Feature
>          Components: VelocityView
>    Affects Versions: 1.3
>            Reporter: Claude Brisson
>            Priority: Minor
>         Attachments: WebappLoader.patch
>
>
> This is another proposal.
> A new "webapp.resource.loader.extension" property that gives a mandatory extension meant to be added to resource names if not already present.
> The typical use-case is when you want to name your templates like "foo.html.vtl" or "foo.js.vtl", without the ".vtl" to be visible in the URLs.
> It is a quite convenient convention since it allows one to store templates and regular files in the same directory tree.
> Needless to say, it is fully backwards compatible.
> This new extension could also be added to other resource loaders, but it would be more complex to factorize, and use-cases are less clear.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org