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: Re: composable RequestProcessor
Date Wed, 04 Jun 2003 16:22:38 GMT
<snip>
I'm not sure why you shouldn't open it up all the way.
</snip>

Sounds good to me. Why stop at the RP. Why not take it all the way to the
action as well?
A lot of people have been clamoring for some kind of method to configurably
compose action functionality in a way that avoids the deadly pitfalls of
'action chaining'.

-----Original Message-----
From: Joe Germuska [mailto:Joe@Germuska.com]
Sent: Thursday, 5 June 2003 00:15
To: Struts Developers List
Subject: RE: Re: composable RequestProcessor


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,proc
essMapping,processRoles,processActionForm,processPopulate,processValidate,pr
ocessForward,processInclude,processActionCreate,processActionPerform,process
ForwardConfig"
>
>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


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