You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Andrew Hill <an...@gridnode.com> on 2003/06/06 07:15:09 UTC
ActionContext [WAS: RE: composable RequestProcessor]
<snip>
I'd even like
create a new execute(StrutsRequestContext) method in the default Action
class, that simple calls the old execute(m, f, r, r) (for backwards
compatibility).
</snip>
Im doing this in my app - though the execute signature remains the same.
Most of my actions extend some abstract action classes, and most of the
hooks the subclass overrides are passed an ActionContext bean (which simply
has getters for the request,response, mapping etc...). Saves a lot of typing
and makes the code much more readable at the expense of one more tiny object
being created in the execute method. I later found it a good place to add
attributes as well - like the request attributes only scoped to the execute
method of the action (life of the ActionContext bean).
Ive been very tempted to overide my applications RPs processActrionPerform
and instantiate the action context there and pass it to the actions execute
but havent got around to it yet.
-----Original Message-----
From: Gary D Ashley Jr. [mailto:garyashley@ToughGuy.net]
Sent: Friday, 6 June 2003 15:02
To: Struts Developers List
Subject: RE: composable RequestProcessor
>Maybe the interface for processor modules should
>take two arguments, a "StrutsRequestContext" like what you described, which
>would have these properties:
>request
>response
>mapping
>form
>path
>Then a second object, "StrutsModuleContext"
>with these properties, with public accessors, only a public mutator
>(setter) for actions:
>servlet
>moduleConfig
>actions (a mapped property)
>This object would be created during RequestProcessor.init(servlet,
>moduleConfig)
I really like this idea, if you had 3 interfaces: StrutsRequestContext,
StrutsModuleContext, and StrutsRequestProcessor.
Then add a StrutsRequestHandler object and moved most of the processXxx
logic into that Handler class. The StrutsRequestProcessor would then only
have 3 methods to implement. init, destroy, and process. This seems like
it would provide the maximum flexibility. Some Struts Extensions may simple
want to forgo using Actions or others parts for completely new ideas, and
some processXxx methods may not apply in all situations (so why be forced to
implement the handful that you can only now conceive of).
So, the ActionServlet would create a StrutsRequestProcessor and a
StrutsModuleContext. Then for each request, it would call the process
method on the StrutsRequestProcessor and pass it a StrutsModuleContext
object and a StrutsRequestContext object.
Then, the RequestProcessor (default implementation) would create a new
StrutsRequestHandler and delegate all the processXxx calls to that object
from its single process method passing each processXxx method the new
Context objects.
This follows the composition by coding view point, at least that is my first
thought.
New extensions to struts wanting to implement custom processing would simple
provide the implementation for the process,init, and destroy methods. The
process method could compose any number of Handlers and delegate most of the
work to those kinds of classes.
For those who desired such a thing, maybe a more complex
StrutsRequestProcessor and StrutsRequestHandler could be created to handle
the compose by configuration way of doing things.
No matter what, I hope a StrutsRequestContext gains support. I'd even like
create a new execute(StrutsRequestContext) method in the default Action
class, that simple calls the old execute(m, f, r, r) (for backwards
compatibility).
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: ActionContext [WAS: RE: composable RequestProcessor]
Posted by Vic Cekvenich <vi...@baseBeans.com>.
I do the same thing in bP! One Context/Event object. Much simpler.
Also, the signature can then support TilesAction signature, , etc.
.V
Peter A. Pilgrim wrote:
> Andrew Hill wrote:
>
>> <snip>
>> I'd even like
>> create a new execute(StrutsRequestContext) method in the default Action
>> class, that simple calls the old execute(m, f, r, r) (for backwards
>> compatibility).
>> </snip>
>>
>> Im doing this in my app - though the execute signature remains the same.
>> Most of my actions extend some abstract action classes, and most of the
>> hooks the subclass overrides are passed an ActionContext bean (which
>> simply
>> has getters for the request,response, mapping etc...). Saves a lot of
>> typing
>> and makes the code much more readable at the expense of one more tiny
>> object
>> being created in the execute method. I later found it a good place to add
>> attributes as well - like the request attributes only scoped to the
>> execute
>> method of the action (life of the ActionContext bean).
>>
>> Ive been very tempted to overide my applications RPs
>> processActrionPerform
>> and instantiate the action context there and pass it to the actions
>> execute
>> but havent got around to it yet.
>>
>
> This is what I do when I extend the base Action and DispatchAction classes.
> I created a context object to store the four parameter. It makes it very
> simple to add extra bits and pass them to actions.
>
> public AcmeActionContext extends ActionContext {
>
> ActionMapping mapping;
> ActionForm form;
> HttpServletRequest request;
> HttpServletResponse response;
>
> ...
>
> LoginProfile loginProfile = SomeSecurityLayer.getInstance();
>
> }
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: ActionContext [WAS: RE: composable RequestProcessor]
Posted by "Peter A. Pilgrim" <pe...@xenonsoft.demon.co.uk>.
Andrew Hill wrote:
> <snip>
> I'd even like
> create a new execute(StrutsRequestContext) method in the default Action
> class, that simple calls the old execute(m, f, r, r) (for backwards
> compatibility).
> </snip>
>
> Im doing this in my app - though the execute signature remains the same.
> Most of my actions extend some abstract action classes, and most of the
> hooks the subclass overrides are passed an ActionContext bean (which simply
> has getters for the request,response, mapping etc...). Saves a lot of typing
> and makes the code much more readable at the expense of one more tiny object
> being created in the execute method. I later found it a good place to add
> attributes as well - like the request attributes only scoped to the execute
> method of the action (life of the ActionContext bean).
>
> Ive been very tempted to overide my applications RPs processActrionPerform
> and instantiate the action context there and pass it to the actions execute
> but havent got around to it yet.
>
This is what I do when I extend the base Action and DispatchAction classes.
I created a context object to store the four parameter. It makes it very
simple to add extra bits and pass them to actions.
public AcmeActionContext extends ActionContext {
ActionMapping mapping;
ActionForm form;
HttpServletRequest request;
HttpServletResponse response;
...
LoginProfile loginProfile = SomeSecurityLayer.getInstance();
}
--
Peter Pilgrim
__ _____ _____ _____
/ //__ // ___// ___/ + Serverside Java
/ /___/ // /__ / /__ + Struts
/ // ___// ___// ___/ + Expresso Committer
__/ // /__ / /__ / /__ + Independent Contractor
/___//____//____//____/ + Intrinsic Motivation
On Line Resume
||
\\===> `` http://www.xenonsoft.demon.co.uk/no-it-striker.html ''
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: ActionContext [WAS: RE: composable RequestProcessor]
Posted by Ted Husted <hu...@apache.org>.
Andrew Hill wrote:
> Im doing this in my app - though the execute signature remains the same.
> Most of my actions extend some abstract action classes, and most of the
> hooks the subclass overrides are passed an ActionContext bean (which simply
> has getters for the request,response, mapping etc...). Saves a lot of typing
> and makes the code much more readable at the expense of one more tiny object
> being created in the execute method. I later found it a good place to add
> attributes as well - like the request attributes only scoped to the execute
> method of the action (life of the ActionContext bean).
>
> Ive been very tempted to overide my applications RPs processActrionPerform
> and instantiate the action context there and pass it to the actions execute
> but havent got around to it yet.
On a similar note, back before we started on the modules, I was working
on a "Struts API bean".
The idea here was to encapsulate all of the various resources that
Struts tucks under the various scopes under various name into one
unified JavaBean, which would be created and placed into each request.
http://cvs.apache.org/viewcvs/jakarta-struts/src/share/org/apache/struts/config/ConfigHelperInterface.java
http://cvs.apache.org/viewcvs/jakarta-struts/src/share/org/apache/struts/config/ConfigHelper.java
Originally, the idea was to help expose Struts to any arbitrary
presentation system that could access a JavaBean. But the approach might
also help with conforming the processXYZ signatures, among other things.
After the "Shock and Awe" of the BIG CHECK-IN, I decided to hold off
until we removed the module deprecations and the code base stabalized
... which might actually start to happen soon =:0)
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org