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