VelocityServlet.handleRequest Questions...

[Jeff Duska <Je...@noaa.gov>]

I've got some questions about the handleRequest method. It appears that 
in version 1.1, a new method signature was created

public Template handleRequest( HttpServletRequest, HttpServletResponse, 
Context ) replacing the previous
public Template handleRequest( Context )

I would think that I should be using/overriding public Template 
handleRequest( HttpServletRequest, HttpServletResponse, Context )
I noticed that both forums demo and the documentation  examples still use
  
 public Template handleRequest(  Context context )
{
    HttpServletRequest request =  (HttpServletRequest) context.get( 
REQUEST );
    HttpServletResponse response =  (HttpServletResponse) context.get( 
RESPONSE );

   ...
}

instead of
 public Template handleRequest(  HttpServletRequest request, 
HttpServletResponse response, Context context )
{

//  These are no longer needed
//  HttpServletRequest request =  (HttpServletRequest) context.get( 
REQUEST );
//  HttpServletResponse response =  (HttpServletResponse) context.get( 
RESPONSE );

   ...
}

Is there something I've missed?  I think I understand why the request 
and response are still included in the context. It is so the template 
developer has access to them.  Since you are adding all the common 
object, it makes sense do the initalization in VelocityServlet. What I 
don't understand is what did adding the request and response parameters 
gain. The developer already had access to this objects. It was the 
clearest code, but I don't think it was rocket science.


Thanks,

Jeff Duska



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: VelocityServlet.handleRequest Questions...

["Geir Magnusson Jr." <ge...@adeptra.com>]

On 7/24/02 11:47 AM, "Jeff Duska" <Je...@noaa.gov> wrote:

> I've got some questions about the handleRequest method. It appears that
> in version 1.1, a new method signature was created
> 

Yep

> public Template handleRequest( HttpServletRequest, HttpServletResponse,
> Context ) replacing the previous
> public Template handleRequest( Context )
> 
> I would think that I should be using/overriding public Template
> handleRequest( HttpServletRequest, HttpServletResponse, Context )

Yep

> I noticed that both forums demo and the documentation  examples still use
> 
> public Template handleRequest(  Context context )
> {
>   HttpServletRequest request =  (HttpServletRequest) context.get(
> REQUEST );
>   HttpServletResponse response =  (HttpServletResponse) context.get(
> RESPONSE );
> 
>  ...
> }
> 
> instead of
> public Template handleRequest(  HttpServletRequest request,
> HttpServletResponse response, Context context )
> {
> 
> //  These are no longer needed
> //  HttpServletRequest request =  (HttpServletRequest) context.get(
> REQUEST );
> //  HttpServletResponse response =  (HttpServletResponse) context.get(
> RESPONSE );
> 
>  ...
> }
> 
> Is there something I've missed?

Nope.  We're just lazy and sloth-like.  We never went back because we didn't
deprecate.  Maybe we deprecate in 1.4 and get rid of it....

> I think I understand why the request
> and response are still included in the context. It is so the template
> developer has access to them.  Since you are adding all the common
> object, it makes sense do the initalization in VelocityServlet. What I
> don't understand is what did adding the request and response parameters
> gain. The developer already had access to this objects. It was the
> clearest code, but I don't think it was rocket science.

No. Clearly we aren't rocket scientists.... :)

The big difference between the two methods is that the new one allows you to
handle the request completely.

If you return 'null' from handleRequest(req, res, ctx) then VelocityServlet
will just return out of what is effectively the servlet's service method.

If you return 'null' from handleRequest(ctx) VelocityServlet will take
matters into its own hands and show the configured error() output.

geir

-- 
Geir Magnusson Jr. 
Research & Development, Adeptra Inc.
geirm@adeptra.com
+1-203-247-1713



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>