At 14:03 +0200 6/3/03, Matthias Bauer wrote:
One thing I am still not clear about is how granular to define which methods can be overwritten and how they are grouped together. I am saying this, because when looking at TilesRequestProcessor you see that it overwrites three methods: processForwardConfig, internalModuleRelativeForward, internalModuleRelativeInclude

Thus, it is not only the the processXXX methods that must be redefineable. But what is the consequence? Will we need to end up in something like this?

<controller>
<requestProcessor>
<method name="processForwardConfig" subProcessor="TilesSubRequestProcessor">
<method name="internalModuleRelativeForward" subProcessor="TilesSubRequestProcessor">
<method name="internalModuleRelativeInclude" subProcessor="TilesSubRequestProcessor">
<method name="process" subProcessor="WorkflowSubRequestProcessor">
...
</requestProcessor>
</controller>


I guess the final consequence would be to allow each single method of the request processor to be replaced by configuration. Do we really want to do this? I am tempted to say no, but I don't see an alternative right now.

In this specific case, those "internal*" methods are called by "processForward" and "processInclude", each of which have only about four lines of code in the base RequestProcessor. Those four lines of code (basically, "should I even process this Forward (or include)") could be factored out into protected methods that can be called by subclass implementations, or, probably better, the checks could just be implemented in the "process()" template method which manages the overall lifecycle. Then the "internal*" methods would be pushed up into processForward and processInclude and the responsibilities would be clearer -- "process()" has the responsibility for deciding which lifecycle methods to call and in what order, and the methods themselves can be a bit simpler.


I would say that based on what we have now, only "process*" methods should be part of a general interface, or perhaps it makes sense two make two larger interfaces (for Action and Dispatch processing, along the lines suggested by Peter Pilgrim <http://marc.theaimsgroup.com/?l=struts-dev&m=105463092331064&w=2>

Joe

--
--
Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "If nature worked that way, the universe would crash all the time." --Jaron Lanier


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to