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 Tue, 03 Jun 2003 10:02:10 GMT
<snip>
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.
</snip>

This way of having the driving RequestProcessor be the one that implements
process() and calls the other is probably the best way to go IMHO. The
driving request processor will also itself implement all the various
interfaces, and in the absence of a SubRequestProcessor implementing
processXXX the RequestProcessor would call itself for processXXX. (Do we
aditionally want certain SubRequestProcessors to provide support for a chain
of implementors? )

btw: Since the processXXX implementation classes for those overridden parts
are instantiated at startup, rather then having the RequestProcessor pass a
reference to itself each time it calls a SubRequestProcessor we could
perhaps set the reference at instantiation time in each SubRequestProcessor,
or are there drawbacks to this that I havent spotted?

-----Original Message-----
From: Matthias Bauer [mailto:Matthias.Bauer@livinglogic.de]
Sent: Tuesday, 3 June 2003 17:48
To: Struts Developers List
Subject: Re: composable RequestProcessor


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


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