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