struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Germuska <...@Germuska.com>
Subject RE: Re: composable RequestProcessor
Date Wed, 04 Jun 2003 16:15:12 GMT
At 9:36 -0600 6/4/03, Brandon Goodin wrote:
>That sounds very complex. With Validator we are dealing with quantifiable
>results. This is not so cut and dry with RP stuff. With the RP I think we
>would do best not to add anymore complexity than neccessary. One process
>should be ignorant of the other unless data is provided in the Tranfer
>Object to trigger certain behavior of functionality. Can you think of an
>example where this would be neccessary? If your extension has dependencies
>on another extension, I think it would be best to just document it.


My initial reaction was also "too complex," but at least from the way 
Ted has presented it, there's not even anyway for the Struts 
developers to stop it!

At 7:04 -0400 6/4/03, Ted Husted wrote:
>process="processLocale,processContent,processNoCache,processPreprocess,processMapping,processRoles,processActionForm,processPopulate,processValidate,processForward,processInclude,processActionCreate,processActionPerform,processForwardConfig"
>
>where each of these have been defined as a Subprocessor (e.g. Validator).
>
>As it stands, many of the process methods take different signatures 
>and return different objects. But that could be changed so that they 
>pass around a single data transfer object with a place for all the 
>usual objects (request,response,mapping,form,action,forward).
>
>Whether each component in this sequence is systemically compatible 
>or whether the order of the processes makes sense, would be the 
>developer's responsibility, just as it is for defining a chain of 
>Validators.

Not that we have to use Ted's configuration syntax.  However, the 
alternative I think of is to have a bunch of named attributes like 
this:

processLocale="com.foo.RequestProcessor"
processContent="com.foo.RequestProcessor"
processNoCache="org.bar.RequestProcessor"
processPreprocess="org.bar.RequestProcessor"
...

with a fallback for undefined stages to a default behavior.  From a 
strict valid-XML standpoint, this is not very extensible, but if the 
goal is to control things, that may be good.  But once you open the 
general topic of a highly configurable request processing chain, I'm 
not sure why you shouldn't open it up all the way.  If there were a 
default configuration file like the default validation rules, and if 
you could make named groups of processes like ANT or Maven 
dependencies, then the complexity for most people would be invisible, 
while the flexibility would be available.

I don't have a very strong opinion on this.  Anyone have comparisons 
from other webapp frameworks?  I'm kind of suspicious of the 
comparison to build tools - yes, the syntax is similar, but the use 
cases aren't.

Joe

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

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