You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Anthony Kay <aw...@yahoo.com> on 2003/02/02 21:50:53 UTC

The RequestUtils interface

I have recently started working with the velocity tools for struts 
in order to add struts 1.1 support. I've noticed that almost all of
the code that does real work is simply a re-write of what is in
the existing struts RequestUtils class.

The problem is that the methods of RequestUtils were written to take
a PageContext in order to get the request, session, and applet context
objects, which is fine for JSP custom tag support, but display tools
for non-JSP systems do not have a PageContext.

My suggestion (and I am willing to contribute the code) is to add 
methods to the interface of RequestUtils that accept the request,
servlet context, etc. as parameters. The work code would migrate to
these, and the existing methods would extract the pieces from the
PageContext and delegate.

For example:

ModuleConfig getModuleConfig(PageContext pageContext)
{
   return getModuleConfig(pageContext.getRequest(), 
                          pageContext.getServletContext());
}

ModuleConfig getModuleConfig(HttpServletRequest request, 
                             ServletContext application)
{
   // existing code in RequestUtils, using new parameter names
}

Comments?

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org


Re: The RequestUtils interface

Posted by Anthony Kay <aw...@yahoo.com>.
That sounds like a winner. 

--- Ted Husted <hu...@apache.org> wrote:
> To get things started, how about we port RequestUtils to Velocity
> Tools 
> and refactor it there to handle for both Velocity and JSP (anything 
> else?). Then once 1.1 ships, we can patch the Struts nightly build
> and 
> deprecate the version in the Velocity-Tools CVS.
> 
> I wouldn't mind being able to use some of the Struts 1.1 features,
> like 
> the Message queue right now.
> 
> -Ted.
> 
> Anthony Kay wrote:
> > 
> >>Ted said:
> >>...
> >>
> >>>The RequestUtils package is really the "JspRequestUtils" package,
> >>
> >>and
> >>
> >>>probably should stay that way.
> >>
> >>Nathan:
> >>Hmm.  Then perhaps it should be so named. :)
> >>
> >>
> >>>The much better route, IMHO, is for other
> >>>presentation devices to do their own, optimized versions of
> >>
> >>RequestUtils.
> >>
> >>perhaps, but on the other hand, a more generalized and central
> >>RequestUtils
> >>would make it easier to keep all varying presentation layers in
> sync
> >>as
> >>Struts continues to evolve.  i could go either way.
> > 
> > 
> > This was really my main point. The code in the velocity tools
> > ends up being nearly identical to the RequestUtils code. A set of
> > methods, particularly those like computeURL(), that would
> centralize
> > the assembly of the internal struts mechanisms and data for the
> > presentation layer would save a lot of duplicated effort on
> > many fronts.
> > 
> > 
> >>>I do have a few tweaks of my own for the Velocity Tools package.
> >>
> >>Should
> >>
> >>>I send you the patches to review, Anthony?
> >>
> > 
> > Sure, love to see them.
> > You can drop them into my mail at awkay69@yahoo.com if
> > you'd like. I have my own version working with modules for the 
> > features I use, but I haven't tested everything yet.
> > If you already have a port, I can find more useful things to do
> > with my spare time :-) 
> > 
> > Anthony Kay
> > 
> > 
> > __________________________________________________
> > Do you Yahoo!?
> > Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
> > http://mailplus.yahoo.com
> > 
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: struts-dev-help@jakarta.apache.org
> > 
> > 
> 
> 
> -- 
> Ted Husted,
> Struts in Action <http://husted.com/struts/book.html>
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
> 


__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org


Re: The RequestUtils interface

Posted by Ted Husted <hu...@apache.org>.
To get things started, how about we port RequestUtils to Velocity Tools 
and refactor it there to handle for both Velocity and JSP (anything 
else?). Then once 1.1 ships, we can patch the Struts nightly build and 
deprecate the version in the Velocity-Tools CVS.

I wouldn't mind being able to use some of the Struts 1.1 features, like 
the Message queue right now.

-Ted.

Anthony Kay wrote:
> 
>>Ted said:
>>...
>>
>>>The RequestUtils package is really the "JspRequestUtils" package,
>>
>>and
>>
>>>probably should stay that way.
>>
>>Nathan:
>>Hmm.  Then perhaps it should be so named. :)
>>
>>
>>>The much better route, IMHO, is for other
>>>presentation devices to do their own, optimized versions of
>>
>>RequestUtils.
>>
>>perhaps, but on the other hand, a more generalized and central
>>RequestUtils
>>would make it easier to keep all varying presentation layers in sync
>>as
>>Struts continues to evolve.  i could go either way.
> 
> 
> This was really my main point. The code in the velocity tools
> ends up being nearly identical to the RequestUtils code. A set of
> methods, particularly those like computeURL(), that would centralize
> the assembly of the internal struts mechanisms and data for the
> presentation layer would save a lot of duplicated effort on
> many fronts.
> 
> 
>>>I do have a few tweaks of my own for the Velocity Tools package.
>>
>>Should
>>
>>>I send you the patches to review, Anthony?
>>
> 
> Sure, love to see them.
> You can drop them into my mail at awkay69@yahoo.com if
> you'd like. I have my own version working with modules for the 
> features I use, but I haven't tested everything yet.
> If you already have a port, I can find more useful things to do
> with my spare time :-) 
> 
> Anthony Kay
> 
> 
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
> http://mailplus.yahoo.com
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
> 
> 


-- 
Ted Husted,
Struts in Action <http://husted.com/struts/book.html>


---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org


Re: The RequestUtils interface

Posted by Anthony Kay <aw...@yahoo.com>.

> Ted said:
> ...
> > The RequestUtils package is really the "JspRequestUtils" package,
> and
> > probably should stay that way.
>
> Nathan:
> Hmm.  Then perhaps it should be so named. :)
> 
> > The much better route, IMHO, is for other
> > presentation devices to do their own, optimized versions of
> RequestUtils.
> 
> perhaps, but on the other hand, a more generalized and central
> RequestUtils
> would make it easier to keep all varying presentation layers in sync
> as
> Struts continues to evolve.  i could go either way.

This was really my main point. The code in the velocity tools
ends up being nearly identical to the RequestUtils code. A set of
methods, particularly those like computeURL(), that would centralize
the assembly of the internal struts mechanisms and data for the
presentation layer would save a lot of duplicated effort on
many fronts.

> 
> > I do have a few tweaks of my own for the Velocity Tools package.
> Should
> > I send you the patches to review, Anthony?

Sure, love to see them.
You can drop them into my mail at awkay69@yahoo.com if
you'd like. I have my own version working with modules for the 
features I use, but I haven't tested everything yet.
If you already have a port, I can find more useful things to do
with my spare time :-) 

Anthony Kay


__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org


Re: The RequestUtils interface

Posted by Nathan Bubna <na...@esha.com>.
Ted said:
...
> The RequestUtils package is really the "JspRequestUtils" package, and
> probably should stay that way.

Hmm.  Then perhaps it should be so named. :)

> The much better route, IMHO, is for other
> presentation devices to do their own, optimized versions of RequestUtils.

perhaps, but on the other hand, a more generalized and central RequestUtils
would make it easier to keep all varying presentation layers in sync as
Struts continues to evolve.  i could go either way.

> I do have a few tweaks of my own for the Velocity Tools package. Should
> I send you the patches to review, Anthony?

The velocity-dev list would be a great place to share those.  :-)

Nathan Bubna
nathan@esha.com


---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org


Re: The RequestUtils interface

Posted by Ted Husted <hu...@apache.org>.
Personally, I would suggest that the existing 
org.apache.velocity.tools.struts.StrutsUtils package be extended to 
incorporate module support, the ActionMessage queue, or whatever other 
Struts 1.1 feature you're after. (I'm using the current version with B3 
now, and it works like a charm.)

The RequestUtils package is really the "JspRequestUtils" package, and 
probably should stay that way. The much better route, IMHO, is for other 
presentation devices to do their own, optimized versions of RequestUtils.

I do have a few tweaks of my own for the Velocity Tools package. Should 
I send you the patches to review, Anthony?

-Ted.

Anthony Kay wrote:
> I have recently started working with the velocity tools for struts 
> in order to add struts 1.1 support. I've noticed that almost all of
> the code that does real work is simply a re-write of what is in
> the existing struts RequestUtils class.
> 
> The problem is that the methods of RequestUtils were written to take
> a PageContext in order to get the request, session, and applet context
> objects, which is fine for JSP custom tag support, but display tools
> for non-JSP systems do not have a PageContext.
> 
> My suggestion (and I am willing to contribute the code) is to add 
> methods to the interface of RequestUtils that accept the request,
> servlet context, etc. as parameters. The work code would migrate to
> these, and the existing methods would extract the pieces from the
> PageContext and delegate.
> 
> For example:
> 
> ModuleConfig getModuleConfig(PageContext pageContext)
> {
>    return getModuleConfig(pageContext.getRequest(), 
>                           pageContext.getServletContext());
> }
> 
> ModuleConfig getModuleConfig(HttpServletRequest request, 
>                              ServletContext application)
> {
>    // existing code in RequestUtils, using new parameter names
> }
> 
> Comments?
> 
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
> http://mailplus.yahoo.com
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
> 
> 


-- 
Ted Husted,
Struts in Action <http://husted.com/struts/book.html>


---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org


Re: The RequestUtils interface

Posted by "Craig R. McClanahan" <cr...@apache.org>.

On Sun, 2 Feb 2003, Anthony Kay wrote:

> Date: Sun, 2 Feb 2003 12:50:53 -0800 (PST)
> From: Anthony Kay <aw...@yahoo.com>
> Reply-To: Struts Developers List <st...@jakarta.apache.org>
> To: struts-dev@jakarta.apache.org
> Subject: The RequestUtils interface
>
>
> I have recently started working with the velocity tools for struts
> in order to add struts 1.1 support. I've noticed that almost all of
> the code that does real work is simply a re-write of what is in
> the existing struts RequestUtils class.
>
> The problem is that the methods of RequestUtils were written to take
> a PageContext in order to get the request, session, and applet context
> objects, which is fine for JSP custom tag support, but display tools
> for non-JSP systems do not have a PageContext.
>
> My suggestion (and I am willing to contribute the code) is to add
> methods to the interface of RequestUtils that accept the request,
> servlet context, etc. as parameters. The work code would migrate to
> these, and the existing methods would extract the pieces from the
> PageContext and delegate.
>
> For example:
>
> ModuleConfig getModuleConfig(PageContext pageContext)
> {
>    return getModuleConfig(pageContext.getRequest(),
>                           pageContext.getServletContext());
> }
>
> ModuleConfig getModuleConfig(HttpServletRequest request,
>                              ServletContext application)
> {
>    // existing code in RequestUtils, using new parameter names
> }
>
> Comments?
>

I think this would make an excellent improvement for Struts 1.2, but would
be a little disruptive at this stage of the game for 1.1.  The best way to
ensure that your work gets captured would be to submit an enhancement
request in the bug tracking system:

  http://nagoya.apache.org/bugzilla/

and start attaching your proposed patches to it.

Craig

---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org