--- Matthias
Andrew Hill wrote:
<snip> This leads to a proliferation of classes. The standard Java way of dealing with large interfaces it to provide an Adapter class that people can subclass and override the few methods they need. </snip>
I can see how your worried that we will end up with a truckload of classes - and we certainly will end up with a lot more interfaces (<drool/>) (might be an idea to have a requestprocessor package!) but I still reckon your missing the point mate.
The idea is to be able to break out the different bits of RP functionality into different classes that you can plug in to customise that specific process *if necessary*. Now these dont HAVE to be different classes, but the idea is to allow them to be if you have to so that your not stuck with the current situation of one big uberProcessor that is a take it or leave it proposition (well ok, so you can subclass it of course, but that doesnt really make life easy if you also need to subclass another one for other bits of the functionality).
Id say most of the time you would - as now - use the standard request processor that comes with struts *however* you can specifically override certain bits of it to do what you need. You can do this now of course, but the difference in the multiple interface approach is that Joe User can take the processXXX class from struts extension FOO and the processYYY class from extension BAR and use them together without having to analyse the source and write his own third class to unite the two in some kind of dodgy shotgun marraige.
(Obviously if both need to override processXXX then there are going be some problems (unless XXX is something that ALSO happens to be amenable to chaining) but based on the comments from other people Id reckon this is rare enough to come into the 20 rather than the 80 (for those who believe in the 80/20 rule))
-----Original Message----- From: David Graham [mailto:[EMAIL PROTECTED] Sent: Monday, 2 June 2003 22:41 To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: composable RequestProcessor
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...
This leads to a proliferation of classes. The standard Java way of dealing with large interfaces it to provide an Adapter class that people can subclass and override the few methods they need.
David
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
That's exactly what I had in mind.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.
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]
_________________________________________________________________ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail
--------------------------------------------------------------------- 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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
