On Wed, 2007-07-11 at 08:43 -0700, Nathan Bubna wrote: > All incarnations of the VelocityViewServlet (and kin) provide > transparent, out-of-the-box access to all request attributes (and > more) in the context. The request doesn't so much operate as the > context, as it does serve to back the context (along with the session > & servlet context) in a chained lookup.
Yes. I like it alot. In the past I have been using servlet filters in front of the VelocityViewServlet to provide control logic to the template. On my more recent projects I have only been sticking things in the request object that the template needs. (The only thing I don't like is communicating what is in the request to template authors... for (obj in req) ...) I have been seeing some interesting blog posts about server side JS and thinking about switching from filters to JS scripts. http://steve-yegge.blogspot.com/2007/06/rhino-on-rails.html http://ajaxian.com/archives/javascript-running-to-the-server >From Rhino it seems relatively easy to stick a 'RhinoFilter' in front of the VelocityViewServlet and have it delegate control off to some JS (based on naming conventions, or some URL mapping config or both). There would of course need to be some JS script compilation and/or caching Any criticisms about this approach would be great. I have seen and played a bit with phobos (https://phobos.dev.java.net/) but it seems to have a lot more than I need. best, -Rob --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
