> -----Original Message-----
> From: David Graham [mailto:[EMAIL PROTECTED]
>
>
> >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?
An interface should be easy to construct aggregated request processors.
If you are saying
import org.apache.struts.mythical.RequestProcessorInterface;
class FooRequestProcessor implements RequestProcessorInterface
{
RequestProcessInterface tiles = new TilesRequestProcessor();
RequestProcessInterface jndi = new JndiRequestProcessor();
public Action doForward( ... ) {
return tiles.doForward( ... );
}
public void processRole( ... ) {
jndi.processRole(...);
}
public void processRole( ... ) {
jndi.processRole(...);
}
public void processBoth( ... ) { // Invented method!!
jndi.processBoth(...);
tiles.processBoth(...);
}
}
Yes. You can get away with interface. Obviously it is not
the generic ideal solution, but you can aggregate the functionality
of the request processor however you like. Sure coding is a pain.
Yes. It is also backwards compatible with 1.1RC1/CVS
Deja vu multiple inheritance C++/. Surely not?!
--
Peter Pilgrim,
Struts/J2EE Consultant, RBoS FM, Risk IT
Tel: +44 (0)207-375-4923
***********************************************************************
Visit our Internet site at http://www.rbsmarkets.com
This e-mail is intended only for the addressee named above.
As this e-mail may contain confidential or privileged information,
if you are not the named addressee, you are not authorised to
retain, read, copy or disseminate this message or any part of it.
The Royal Bank of Scotland plc is registered in Scotland No 90312
Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB
Regulated by the Financial Services Authority
***********************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
