Well I see little point in defining an interface that simply requires you to
implement all the hooks in the RP.
It doesnt seem to get us any further than where we are already (well apart
from satisfying my compulsive desires for more interfaces!)
You need to break it out into multiple discrete interfaces so you can do
something like:
public class BobRequestSubprocessor implements RoleProcessor,
ActionFormProcessor
{
public void processRole(...) {
...
}
public ActionForm processActionForm(...) {
...
}
}
Then you can specify a class for each individual processXXX in your
struts-config , and of course the main requestprocessor class itself which
implements the lot and is used as a 'default' where a more specific handler
is not specified...
But I still havent thought of a nice way to resolve 'conflicts'.
For example you have the FOO and the BAR extensions written by different
people and for the sake of example, both need to override something like
processActionForm() ... is a generic way of handling this a possibility?
This sort of method isnt conceptually amenable to chaining as it has to
return a single value, and yet both extensions RPs need to do their own
thing here. I guess that sort of method simply has to have specific code
that is written to unite the two RPs , such as what MB has had to do to
marry workflow and tiles under the current architecture...
-----Original Message-----
From: David Graham [mailto:[EMAIL PROTECTED]
Sent: Monday, 2 June 2003 22: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
:-).
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).
David
>--
>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]
>
_________________________________________________________________
MSN 8 with e-mail virus protection service: 2 months FREE*
http://join.msn.com/?page=features/virus
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
