On Mar 1, 2009, at 9:41 PM, Michal Charemza wrote:
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.
Which you don't need if you keep the user on the same page when there is an error.
I almost need data to be 'half validated'. That is, it must cause thehandle***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.
"Never say never" they say. The main reason to redirect the user after completing a form is to prevent him from submitting the same data twice which can be anything from a nuisance - two newsletter registrations on the same address - to a major problem - oops, just ordered two of those 4k flatscreen panels? But that does not apply if you're redirecting after each valid submission an just keep the user on the old url if there is an error. You're not accepting the data anyways. In case you write the form data to the session - what happens if the user fills in two forms on your site in two tabs? How are you going to take care of not mixing and messing those errors up?
Please note that I'm not commenting on the article you mention, reading it requires a subscription.
Is this a bad idea?
Well, see how much handling of data and state you suddenly need to add to a stateless protocol and compare it with the simpler solution. Consider the tradeoffs, maybe build a short sample or try the usual clickflows on the sample app. It does have a form submission. Then answer your own question.
Michal.
Cheers felix
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ users mailing list [email protected] http://lists.agavi.org/mailman/listinfo/users
