> -----Original Message-----
> From: David Graham [mailto:[EMAIL PROTECTED]
> Sent: 02 June 2003 15:12
> To: [EMAIL PROTECTED]
> Subject: RE: composable RequestProcessor
>
>
> >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(...);
> > }
> >}
>
> That's exactly what I had in mind.
>
> >
> >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.
>
> Can you explain why it's not generic, ideal, and a pain to
> code? To me, it
> looks straightforward. Remember that this functionality is
> to support the
> *few* people that will need it. Most Struts apps will use
> the standard
> RequestProcessor or TilesRequestProcessor. Simple is better
> in edge cases
> :-).
Why of course. It's the oldest adage in the book.
You dont get nothing for free! You must code.
> If we want to configure each method of the processor in
> struts-config.xml we
> may as well design it as Servlet Filters.
>
> >
> >Yes. It is also backwards compatible with 1.1RC1/CVS
> >
> >Deja vu multiple inheritance C++/. Surely not?!
>
> This is standard OO composition, not a mimic of multiple
> inheritance (yuck).
For my purposes then a interface approach would work.
This is the simplest. I want to the same flexible
as I have in the `ExpressoRequestProcessor'. Ok I am
no longer subclassing `TilesRequestProcessor' but I
am now aggregating. I do not care really. What is important
is that the next guy can take my expresso
controller and also aggregate in his
`BigInvestmentBankRequestProcessor' /. Also if I decide
to aggregate in `ExpressoRequestProcessor' new
`FandangleRequestProcessor' my big investment bank
customer also gets that as a bonus.
But there is nothing to prevent the most ardent coder
building the XML configuration composable
controller if he or she wants to.
Compatibility, compability, compability.
Comprehende, cappiche, understand.
--////--
--
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]
