Re: composable RequestProcessor

[Matthias Bauer]

One thing I am still not clear about is how granular to define which 
methods can be overwritten and how they are grouped together. I am 
saying this, because when looking at TilesRequestProcessor you see that 
it overwrites three methods: processForwardConfig, 
internalModuleRelativeForward, internalModuleRelativeInclude

Thus, it is not only the the processXXX methods that must be 
redefineable. But what is the consequence? Will we need to end up in 
something like this?

<controller>
 <requestProcessor>
    <method name="processForwardConfig" 
subProcessor="TilesSubRequestProcessor">
    <method name="internalModuleRelativeForward" 
subProcessor="TilesSubRequestProcessor">
    <method name="internalModuleRelativeInclude" 
subProcessor="TilesSubRequestProcessor">
    <method name="process" subProcessor="WorkflowSubRequestProcessor">
    ...
 </requestProcessor>
</controller>

I guess the final consequence would be to allow each single method of 
the request processor to be replaced by configuration. Do we really want 
to do this? I am tempted to say no, but I don't see an alternative right 
now.

--- Matthias



Andrew Hill wrote:

Yep. Having a look at the processXXX methods in the RP Id say that most
arent really amenable to chaining anyhow.
(One likely exception is the processPreprocess() hook, however if chaining
is required for this it could perhaps be done by an implementation of its
interface 'PreprocessProcessor' that has the logic to call multiple other
PreprocessProcessor implementations.)
Im guessing that for the configuration flexibility we need, we will want to
add more xml elements in struts-config as child elements of the controller
element that can provide the necessary info, Id prefer this to just having a
whole bunch of extra attribute directly hanging off the controller element.
-----Original Message-----
From: Matthias Bauer [mailto:[EMAIL PROTECTED]
Sent: Tuesday, 3 June 2003 18:10
To: Struts Developers List
Subject: Re: composable RequestProcessor
 

<snip>
This driving request processor who selects the instances of the sub
request processors should be the one who keeps the members. Every sub
request processor must be allowed to modify these members. Therefore the
driving request processor must pass a reference to himself to each
method now (like in the above sample code). The members that are exposed
(e. g. the action map)  must be accessible with getter methods then.
</snip>
This way of having the driving RequestProcessor be the one that implements
process() and calls the other is probably the best way to go IMHO. The
driving request processor will also itself implement all the various
interfaces, and in the absence of a SubRequestProcessor implementing
processXXX the RequestProcessor would call itself for processXXX. (Do we
aditionally want certain SubRequestProcessors to provide support for a
   

chain
 

of implementors? )

   

In my opinion it is enough to go without chaining support.

 

btw: Since the processXXX implementation classes for those overridden parts
are instantiated at startup, rather then having the RequestProcessor pass a
reference to itself each time it calls a SubRequestProcessor we could
perhaps set the reference at instantiation time in each
   

SubRequestProcessor,
 

or are there drawbacks to this that I havent spotted?

   

I don't think there are any drawbacks. It will definitely make sense to
establish the references at startup time. This is also the approach I am
going in the workflow extension.
--- Matthias



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



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]