On 1 Mar 2009, at 20:12, Felix Gilcher wrote: >> This >> makes me think that something has to be done in the validation code >> to >> allow invalid data to persist between requests. > > Why? For what reason would you keep data that you know that it's > invalid by your own rules? So that on the next request the FPF fills the forms with the submitted data. This is just to keep the form exactly as the user entered it.
>> I almost need data to be 'half validated'. That is, it must cause the >> handle***Error action method to be called, but still allow invalid >> data to be passed to the view. >> >> Or am I just barking up the wrong tree? All I want is the standard >> Post/Redirect/Get pattern... >> >> >> - Post a form >> - Redirect to a GET >> - If there has been an error, show the form again, with the errors >> and >> the previously submitted data. > > You are barking up the wrong tree. The proper way to do this is: > > - POST a form > - if validation succeeds, process the data in your actions > 'executeWrite' and then redirect > - if validations fails or another error occured, don't redirect. > Display the form with all the error messages. > > No need to store the errors in a session or the like. Although (obviously!!) I am not experienced in this, I have read pages like http://www.theserverside.com/tt/articles/article.tss?l=RedirectAfterPost . This page specifically says "Never show pages in response to POST ". Essentially I'm trying to make sure the back button never ends up with one of those annoying 'do you want to resubmit data' messages. Is this a bad idea? Michal. _______________________________________________ users mailing list [email protected] http://lists.agavi.org/mailman/listinfo/users
