struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matthias Bauer <Matthias.Ba...@livinglogic.de>
Subject Re: composable RequestProcessor
Date Tue, 03 Jun 2003 06:43:44 GMT
I am very much in line with you. Where do we go from now? It would be a 
pity if we let the ideas drain, we discussed here.

--- 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: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
>
>  
>



---------------------------------------------------------------------
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