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