struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Graham" <dgraham1...@hotmail.com>
Subject Re: composable RequestProcessor
Date Tue, 03 Jun 2003 13:51:36 GMT
>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.

Somewhere along the way in this discussion, simplicitly was lost.  
Configuring each method in struts-config and separating RP into many 
interfaces seems like overkill to me.  You lose the ability to truly compose 
behavior with the struts-config approach.  You can't do this in xml:

public processActionCreate() {
  super();  //do parent behavior
  tilesRP.processActionCreate();  // do tiles
  // do some  custom stuff
  someotherRP.processActionCreate();
}

David


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

_________________________________________________________________
Add photos to your e-mail with MSN 8. Get 2 months FREE*.  
http://join.msn.com/?page=features/featuredemail


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