Thanks, Joe: see within:
<SNIP> On Wed, 23 Feb 2005 08:25:07 -0600, Joe Germuska <[EMAIL PROTECTED]> wrote: > I am talking about what happens before the action class is executed, > including the possible decision not to execute the action because > form validation was required and failed. </SNIP> Gotcha! <SNIP> > Actually, I just about never have discussions with other committers > besides what's here on the dev list; however, perhaps we've been > having these discussions together long enough that we gloss over some > things. </SNIP> 10-4! Makes sense! <SNIP> > Anyway, from my personal experience, when one wants to apply control > logic that is common to various requests (as opposed to based in a > single Action), the chain based request processor has made that > simpler for me. </SNIP> This is hard for me to follow. I am not sure what "control logic that is common to various request" would be, so I cannot see how the "composable request processor" (I like that way of talking about it) helps here. <SNIP> > As for reusable extensions to the request processing > cycle, I think we will find that building those is simpler too, once > people start absorbing this. Some of the earliest discussions > about needing a composable request processor came up in the context > of the struts-workflow project, which faced a challenge in wanting to > provide custom request processing and needing to figure out how to > work with users who may or may not have wanted to use Tiles, since > Tiles also required a subclass of RequestProcessor. </SNIP> 10-4! Is there going to be a mechanism for plugging extensions in at each stage in the final analysis? That would be ideal, to my mind. Jack -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
