You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by "Geir Magnusson Jr." <ge...@optonline.net> on 2001/02/05 08:27:25 UTC
transparent changes to VelocityServlet
I implemented a few changes, derivative if not outright stolen from
Christoph's ideas :), to VelocityServlet, and put it up in
whiteboard/geir. These changes are transparent to current users - but
encapsulate the primary parts of the servlet processing as separate
methods so they could be overridden.
They are all called from within doRequest(), have default
implementations that behave as the current implementation, and are :
protected Context createContext(HttpServletRequest request,
HttpServletResponse response ) : to allow the servlet author to create
and fill/wrap the context to be used in template processing
protected void setContentType( HttpServletRequest request,
HttpServletResponse response ) : sets the content type - the current
impl just doesn't work... This gives the servlet author a change to
examine the request, and alter the content type on a per-request basis.
protected abstract Template handleRequest( Context ctx ) : as is - still
abstract, because I think the servlet author should do *something*....
I really detest that we don't pass the request and response directly as
args, but have to pass them through the context....
protected void mergeTemplate( Template template, Context context,
HttpServletResponse response ) : does the merging of the template
returned by handleRequest with the context. This hopefully shouldn't
need to be overridden.
Comments? If nothing wrong, I will check in tomorrow...
geir
--
Geir Magnusson Jr. geirm@optonline.com
Velocity : it's not just a good idea. It should be the law.
http://jakarta.apache.org/velocity
Re: transparent changes to VelocityServlet
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Christoph Reck wrote:
>
> I tested the VelocityServlet in the whiteboard/geir and all is OK
> (with my application, and as stated before, meticolous review shows
> that it is compatible with original version).
>
> +1 to check it in.
Thanks. Any thoughts on the specific methods and their signatures? Are
there other ways to slice and dice the flow that make more sense?
> :) Christoph
>
> "Geir Magnusson Jr." wrote:
> >
> > I implemented a few changes, derivative if not outright stolen from
> > Christoph's ideas :), to VelocityServlet, and put it up in
> > whiteboard/geir. These changes are transparent to current users - but
> > encapsulate the primary parts of the servlet processing as separate
> > methods so they could be overridden.
> >
> > They are all called from within doRequest(), have default
> > implementations that behave as the current implementation, and are :
> >
> > protected Context createContext(HttpServletRequest request,
> > HttpServletResponse response ) : to allow the servlet author to create
> > and fill/wrap the context to be used in template processing
> >
> > protected void setContentType( HttpServletRequest request,
> > HttpServletResponse response ) : sets the content type - the current
> > impl just doesn't work... This gives the servlet author a change to
> > examine the request, and alter the content type on a per-request basis.
> >
> > protected abstract Template handleRequest( Context ctx ) : as is - still
> > abstract, because I think the servlet author should do *something*....
> > I really detest that we don't pass the request and response directly as
> > args, but have to pass them through the context....
> >
> > protected void mergeTemplate( Template template, Context context,
> > HttpServletResponse response ) : does the merging of the template
> > returned by handleRequest with the context. This hopefully shouldn't
> > need to be overridden.
> >
> > Comments? If nothing wrong, I will check in tomorrow...
> >
> > geir
--
Geir Magnusson Jr. geirm@optonline.com
Velocity : it's not just a good idea. It should be the law.
http://jakarta.apache.org/velocity
Re: transparent changes to VelocityServlet
Posted by Christoph Reck <Ch...@dlr.de>.
I tested the VelocityServlet in the whiteboard/geir and all is OK
(with my application, and as stated before, meticolous review shows
that it is compatible with original version).
+1 to check it in.
:) Christoph
"Geir Magnusson Jr." wrote:
>
> I implemented a few changes, derivative if not outright stolen from
> Christoph's ideas :), to VelocityServlet, and put it up in
> whiteboard/geir. These changes are transparent to current users - but
> encapsulate the primary parts of the servlet processing as separate
> methods so they could be overridden.
>
> They are all called from within doRequest(), have default
> implementations that behave as the current implementation, and are :
>
> protected Context createContext(HttpServletRequest request,
> HttpServletResponse response ) : to allow the servlet author to create
> and fill/wrap the context to be used in template processing
>
> protected void setContentType( HttpServletRequest request,
> HttpServletResponse response ) : sets the content type - the current
> impl just doesn't work... This gives the servlet author a change to
> examine the request, and alter the content type on a per-request basis.
>
> protected abstract Template handleRequest( Context ctx ) : as is - still
> abstract, because I think the servlet author should do *something*....
> I really detest that we don't pass the request and response directly as
> args, but have to pass them through the context....
>
> protected void mergeTemplate( Template template, Context context,
> HttpServletResponse response ) : does the merging of the template
> returned by handleRequest with the context. This hopefully shouldn't
> need to be overridden.
>
> Comments? If nothing wrong, I will check in tomorrow...
>
> geir
Re: transparent changes to VelocityServlet
Posted by Jon Stevens <jo...@latchkey.com>.
on 2/4/01 11:27 PM, "Geir Magnusson Jr." <ge...@optonline.net> wrote:
> protected abstract Template handleRequest( Context ctx ) : as is - still
> abstract, because I think the servlet author should do *something*....
> I really detest that we don't pass the request and response directly as
> args, but have to pass them through the context....
>
I agree with that as well, in fact, that is why the RunData object was
invented in Turbine...to be a container of several objects instead of having
to pass things around one by one...
-jon
--
If you come from a Perl or PHP background, JSP is a way to take
your pain to new levels. --Anonymous
<http://jakarta.apache.org/velocity/> | <http://java.apache.org/turbine/>