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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
