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 09:48:05 GMT
>
>
>Would grouping the interfaces as I have done above actually
>solve this problem? If you have two request processor
>that implemented my `DispatchRequestProcessorInterface '
>as above you would still have the same messy aggregation
>problems as above, albeit is lesser number of methods
>to consider. I am unsure if this is easier.
>
>There is another question here, or couple.
>
>By making a request processor an interface you pass on
>the concrete details, the actual whereabouts of the 
>data attributes and the other object instance data 
>members to some other class X out there. 
>
>If you look at the javadoc for the default `RequestProcessor'
>it has a list collection of Action objects. This is a map collection
>of all the actions that are configured via XML for this module config.
>When you start delegating or aggregating request processors, you
>must ask the question, in which controller has the module `Actions'.
>
>For example
>
>class AcmeRequestProcessor extends RequestProcessor
>implements RequestProcessorInterface 
>{
>    
>     RequestProcessorInterface  tiles = new TilesRequestProcessor();
>    
>     public void whereAreMyActions( ) {
>
>	// Which is the correct collection actions 
>	// for this module config?
>	this.actions.get("/Login.do" );
>	// or 
>	tiles.getAction().get("/Login.do" );
>
>}
>
>I think we have NOT been considering the data members of the
>current default controller (RP).
>  
>
I think you are addressing a good point. Building a set of interfaces is 
certainly not enough. It is not enough anyway, because there must be a 
driving class that implements the method "process". It must instantiate 
the right instances of the sub request processors:

        // Check for any role required to perform this action
        if (null == this.processRolesRequestProcessor) {
           // create it
          this.processRolesRequestProcessor = 
this.createProcessRolesRequestProcessor(...);
        }
        if (!this.processRolesRequestProcessor.processRoles(request, 
response, mapping, this)) {
            return;
        }
        ...

This driving request processor who selects the instances of the sub 
request processors should be the one who keeps the members. Every sub 
request processor must be allowed to modify these members. Therefore the 
driving request processor must pass a reference to himself to each 
method now (like in the above sample code). The members that are exposed 
(e. g. the action map)  must be accessible with getter methods then.


>New accessor and mutators would be required, as I hinted with
>the ``Map getActions()'' call above.
>
>May be this is a "separation of concerns" design. The multiple 
>interface no longer sounds right, especially with the data 
>members. I am starting think there could be performance
>problems if we start delegating calls ad infinitum too.
>  
>
I don't see why this should influence performance. It is just a few more 
function calls that does not add significant weight to the many function 
calls already involved to process a request.

--- Matthias


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