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 10:10:20 GMT
>
>
><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


Mime
View raw message