struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gary D Ashley Jr." <garyash...@ToughGuy.net>
Subject RE: composable RequestProcessor
Date Fri, 06 Jun 2003 07:02:26 GMT
>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: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org


Mime
View raw message