>>I can't think of a good reason it wouldn't call validate() too, like any >>other request, just because the action was canceled. Like I said, maybe someone can come up with a reasonable explanation for that behavior, but I can't see it :)
There is a legitimate case: when an form can be cancelled, you do want to skip client-side and server-side validation. That's just fine because in these case you do want to call the cancelled() method from DispatchAction, dump out any state you collected, and go to the appropriate forward. I want to make sure we don't lose focus here. The problem is not that cancelled doesn't validate, but that ANY action can have its validation bypassed. This is not semantically correct for some actions, especially GET actions whose sole job is to retrieve data without any state except for the request parameters they receive. Usually people cancel form POST input, but not GET input because those could be links in emails, bookmarks, etc. Explain the semantics of canceling a bookmark or a link from an email? It's pretty difficult to think of a general case. So, as I've said before, I do believe there needs to be a switch that determines when by-passing validation IS A VALID USE CASE. Having that feature always be on is logically wrong and creates a world where many stateless requests which use form validation to defend against bad user input is suddenly defeated. Paul __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
