[ 
http://issues.apache.org/jira/browse/VELOCITY-407?page=comments#action_12330561 
] 

Claude Brisson commented on VELOCITY-407:
-----------------------------------------

I thought I would get more approbation than that on this one...

Thanks for rephrasing the description, but how comes you qualify it as 
"extremely specific to a single use case"?

I've got no problem subclassing the VelocityViewServlet for my own use.

The point is that I'm questionning the actual default behaviour, since it looks 
rather obvious
that it's not acceptable for any serious webapp. Where do you see I mention a 
particular use case ?

Go tell a bunch of students that Velocity is a great piece of software, as is 
VelocityTools, but that they should not use the VelocityViewServlet right 
out-of-the-box but better systematically subclass it...

The effort of trying to put some standardization in template naming does not 
seems so exotic to me.

--
Claude


> Templates vs. static content should be resolvable via file naming pattern
> -------------------------------------------------------------------------
>
>          Key: VELOCITY-407
>          URL: http://issues.apache.org/jira/browse/VELOCITY-407
>      Project: Velocity
>         Type: Wish
>   Components: Tools
>     Versions: Tools-1.2
>  Environment: all
>     Reporter: Claude Brisson
>     Priority: Minor

>
> The VelocityViewServlet.getTemplate() method should append ".vtl"
> to the URI by default (and only handle .vtl files in its servlet-mapping
> clause).
> So, a request http://www.foo.com/bar.html would map :
> 1. to a template bar.html.vtl if found
> 2. to a regular html file bar.html otherwise
> Beyond the first basic samples, any webapp will need such a behaviour.
> So all application designers will have to subclass VelocityViewServlet to do 
> it.
> Why not then incorporate it by default ? It looks rather important to me. 
> Having
> to subclass the VelocityViewServlet for each and every project is really 
> silly.
> Since there is a backward compatibility issue, one could trigger the 
> behaviour with
> a configuration flag and wait for the tools 2.0 to have the default changed.

-- 
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to