You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@velocity.apache.org by Robert Koberg <ro...@koberg.com> on 2007/07/11 16:24:01 UTC

using the servlet request object in place of velocity context ??

Hi,

What are the cons of simply using the (Http)ServletRequest object to
store objects for a view template. Or, why use a velocity context when
you already have the request object?

I am thinking of reuse of control logic for different view template
engines. Or different control languages with the same velocity
templates. But really I am looking for any negatives for using only the
request object.

It seems to me if you stick to populating only the request object you
have a much greater ease of changing/adapting/whathaveyou.

thanks,
-Rob


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


Re: using the servlet request object in place of velocity context ??

Posted by Robert Koberg <ro...@koberg.com>.
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: user-unsubscribe@velocity.apache.org
For additional commands, e-mail: user-help@velocity.apache.org


Re: using the servlet request object in place of velocity context ??

Posted by Nathan Bubna <nb...@gmail.com>.
On 7/11/07, Daniel Dekany <dd...@freemail.hu> wrote:
> Wednesday, July 11, 2007, 4:24:01 PM, Robert Koberg wrote:
>
> > Hi,
> >
> > What are the cons of simply using the (Http)ServletRequest object to
> > store objects for a view template. Or, why use a velocity context when
> > you already have the request object?
>
> Velocity is not bound to Servlet-s or HTTP... it may be used to
> generate text in applications that has nothing to do with the Web. So
> it can't just use the ServletRequest as the context by default. If it
> can use the HTTP request directly as the context if you want that, I
> don't know... there is a template engine that can, but I won't tell
> it's name. ;)

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.

> > I am thinking of reuse of control logic for different view template
> > engines. Or different control languages with the same velocity
> > templates. But really I am looking for any negatives for using only the
> > request object.
> >
> > It seems to me if you stick to populating only the request object you
> > have a much greater ease of changing/adapting/whathaveyou.
> >
> > thanks,
> > -Rob
>
> --
> Best regards,
>  Daniel Dekany
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
> For additional commands, e-mail: user-help@velocity.apache.org
>
>

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


Re: using the servlet request object in place of velocity context ??

Posted by Daniel Dekany <dd...@freemail.hu>.
Wednesday, July 11, 2007, 4:24:01 PM, Robert Koberg wrote:

> Hi,
>
> What are the cons of simply using the (Http)ServletRequest object to
> store objects for a view template. Or, why use a velocity context when
> you already have the request object?

Velocity is not bound to Servlet-s or HTTP... it may be used to
generate text in applications that has nothing to do with the Web. So
it can't just use the ServletRequest as the context by default. If it
can use the HTTP request directly as the context if you want that, I
don't know... there is a template engine that can, but I won't tell
it's name. ;)

> I am thinking of reuse of control logic for different view template
> engines. Or different control languages with the same velocity
> templates. But really I am looking for any negatives for using only the
> request object.
>
> It seems to me if you stick to populating only the request object you
> have a much greater ease of changing/adapting/whathaveyou.
>
> thanks,
> -Rob

-- 
Best regards,
 Daniel Dekany


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


Re: using the servlet request object in place of velocity context ??

Posted by Nathan Bubna <nb...@gmail.com>.
i don't know of any cons.  what you are asking about is what i would
recommend for any app using the VelocityViewServlet (and kin).

On 7/11/07, Robert Koberg <ro...@koberg.com> wrote:
> Hi,
>
> What are the cons of simply using the (Http)ServletRequest object to
> store objects for a view template. Or, why use a velocity context when
> you already have the request object?
>
> I am thinking of reuse of control logic for different view template
> engines. Or different control languages with the same velocity
> templates. But really I am looking for any negatives for using only the
> request object.
>
> It seems to me if you stick to populating only the request object you
> have a much greater ease of changing/adapting/whathaveyou.
>
> thanks,
> -Rob
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
> For additional commands, e-mail: user-help@velocity.apache.org
>
>

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