struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Graham" <dgraham1...@hotmail.com>
Subject RE: composable RequestProcessor
Date Mon, 02 Jun 2003 14:41:11 GMT
>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


Mime
View raw message