Actions have some drastically different logical contents that may make them incompatible with other Actions. I'm not sure how you could create a composable Action process without rewriting the whole underlying struts Action architecture. Also, there are other ways to avoid the "pitfalls" of Action chaining. Take a look at Struts Chaining extenstion http://sf.net/projects/strutschaining. I posted an Announcement about Struts Chaining being on sourceforge and on increasing it's flexibility not too long ago. I don't think that compoosable Actions are a good idea to impose on all actions. It is, however, possible to do now, if you need to.
Brandon Goodin -----Original Message----- From: Andrew Hill [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 04, 2003 10:23 AM To: Struts Developers List Subject: RE: Re: composable RequestProcessor <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:[EMAIL PROTECTED] 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 [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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
