If RequestProcessor becomes an interface then you ought invent a RequestProcessorManager interface, which is an object responsible for managing and invoking request processor. In other words we have a manager and worker children.
If not the controller XML needs changing. How about
<manager class="ControllerManager" > <controller class="TilesRequestProcessor" /> <controller class="FoobarRequestProcessor" /> <controller class="AcmeRequestProcessor" /> </manager>
I'm not sure how this is different than the proposal to change the xml to support RequestProcessors on a method level. Struts would invoke the one registered processor and it would be up to that processor to act as manager if needed.
For Expresso I too have subclassed the TilesRequestProcessor for our own ExpressoRequestProcessor. Can a module have more than one controller?
In the future you could have ExpressoRequestProcessor implement a RequestProcessor interface and dispense with the subclassing altogether. Your ExpressoRequestProcessor would act as the manager (using composition) if you needed to invoke multiple processors.
I agree with the XP philosophy that often simpler is better. So, how does the interface not meet your needs?
David
-- Peter Pilgrim
_________________________________________________________________
Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
