[
https://issues.apache.org/jira/browse/VELTOOLS-111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nathan Bubna resolved VELTOOLS-111.
-----------------------------------
Resolution: Fixed
Fix Version/s: 2.0
Yeah, this was already brought up and restored in the trunk. It will be in
the next release. Thanks!
> Suggestion to retain deprecated handleRequest
> ---------------------------------------------
>
> Key: VELTOOLS-111
> URL: https://issues.apache.org/jira/browse/VELTOOLS-111
> Project: Velocity Tools
> Issue Type: Improvement
> Components: VelocityView
> Affects Versions: 1.4, 2.0
> Reporter: Steve Hale
> Priority: Minor
> Fix For: 2.0
>
>
> When migrating from VelocityServlet to VelocityViewServlet, a major headache
> for many will be rewriting handleRequest(req, res, ctx) since it is
> deprecated in VelocityTools 1.4 and said to be omitted starting with 2.0.
> This is particularly true since prior VelocityServlet javadocs say it MUST be
> overridden. It is suggested to leave handleRequest as-is and non-deprecated
> in VelocityViewServlet.
> Apparently the idea is to separate filling the context with data based on the
> request (using fillContext(ctx, req)) from obtaining the template name (using
> getTemplate(req, res)). One difficult example is redirecting to a custom
> error page when the template cannot be found/loaded. This isn't known until
> getTemplate is called well after fillContext, so there isn't a way to put
> additional information into the context from inside getTemplate. Conversely
> fillContext can't do it all since it doesn't have access to res and doesn't
> return the template name. I'm not saying it can't be done, but it seems more
> difficult to workaround than retaining the flexibility to allow users to do
> it either in the combined handleRequest way or the separated
> fillContext/getTemplate approach.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]