>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]
