struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Hill" <andrew.david.h...@gridnode.com>
Subject RE: composable RequestProcessor
Date Mon, 02 Jun 2003 14:57:54 GMT
<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:dgraham1980@hotmail.com]
Sent: Monday, 2 June 2003 22:41
To: andrew.david.hill@gridnode.com; struts-dev@jakarta.apache.org
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:dgraham1980@hotmail.com]
>Sent: Monday, 2 June 2003 22:12
>To: struts-dev@jakarta.apache.org
>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: struts-dev-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail: struts-dev-help@jakarta.apache.org
> >
>
>_________________________________________________________________
>MSN 8 with e-mail virus protection service: 2 months FREE*
>http://join.msn.com/?page=features/virus
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>

_________________________________________________________________
Help STOP SPAM with the new MSN 8 and get 2 months FREE*
http://join.msn.com/?page=features/junkmail


---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org


Mime
View raw message