This could work well. How does this processor pattern solve the problem where the RequestProcessor stores data member? E.g. The list of Actions recorded against a ModuleConfig.
That's a good question. 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
That's all I can see that is handled as variables in the "process" method scope. This would be an object instantiated at the beginning of "process(request,response)". Then a second object, "StrutsModuleContext" with these properties, with public accessors, only a public mutator (setter) for actions:
servlet
moduleConfig
actions (a mapped property)
I guess you could just expose accessors in the RequestProcessor interface for those things, but this approach insulates classes which implement the interface from changes in the idea of a "StrutsModuleContext"
Also, by using this object, you can compromise on making those things truly public because the RequestProcessor is the one who decides when to pass the StrutsModuleContext in to a method call.
This object would be created during RequestProcessor.init(servlet, moduleConfig)
Thoughts?
Joe
--
--
Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "If nature worked that way, the universe would crash all the time." --Jaron Lanier
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
