...Thanks, Joe,
See within:
<SNIP></SNIP>Jack, I'm not really following you. For me, I simply raised the issue that there is a standard conditional case in processing a request for Struts: if the form is valid, then do a few things; if it is not, do a few other things (well, just one, "SelectInput") So I guess this is talking about something which belongs in the "standard plumbing chain."
I don't see a clear way to apply the Strategy pattern to this specific question, but maybe I'm just missing something.
Joe
Are you talking about what happens prior to reaching the Action class or what happens before? I assume you are talking about what happens before, but perhaps I am mistaken?
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.
I am trying to be helpful here, as I had great hopes that some sort of chain option for the request processor would make building plugins and making life simpler. As things are, if this is about the plumbing, things seem to be potentially more rather than less coupled. Sorry if this is not helpful, but you all obviously talk with each other often enough to leave a bit out of the conversation which I cannot get the uptake on.
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.
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. 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.
Joe
--
Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "Narrow minds are weapons made for mass destruction" -The Ex
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
