struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matthias Bauer <Matthias.Ba...@livinglogic.de>
Subject Re: composable RequestProcessor
Date Tue, 03 Jun 2003 12:03:00 GMT
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:Matthias.Bauer@livinglogic.de]
>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: struts-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
>  
>



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