struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Germuska <>
Subject Re: composable RequestProcessor
Date Tue, 03 Jun 2003 14:26:23 GMT
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?
>  <requestProcessor>
>     <method name="processForwardConfig" 
>     <method name="internalModuleRelativeForward" 
>     <method name="internalModuleRelativeInclude" 
>     <method name="process" subProcessor="WorkflowSubRequestProcessor">
>     ...
>  </requestProcessor>
>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 


Joe Germuska       
"If nature worked that way, the universe would crash all the time." 
	--Jaron Lanier

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message