views:

146

answers:

2

I would like to implement form handling for web apps. I'd like to implement PRG (post-redirect-get), as I believe it is the way to go in form handling (plays very nicely with reload and back button). However, I'm seeing that it complicates validation.

Basically, when you post, you have the form state (as post parameters). However, if you validate and redirect back to the form, you lose your form state (your redirect is a GET; you could encode all the form parameters in GET, but that's not always possible, due to URL length restrictions. Also, it looks ugly as hell).

I'm thinking about the following:

  1. User is in the form view (/addUserDetails.html)
  2. POST to action url (/addUser)
  3. /addUser executes the relevant action. If it fails, it stores the form state, assigns an id to it and redirects to the form view, with the id as a get parameter (/addUserDetails.html?state=2313ab2)
  4. The view validates the state and displays the relevant information

Depending on how you store the form state, you might also let the user continue working on the form even if their browser blows up or something bad happens.

Thoughts? Also, is there any Java web framework that does this or can be coerced into doing it?

+1  A: 

You don't have to keep all the states in the redirect URL. I did this a little bit different from your approach and it works great for our use case.

I don't redirect if the form doesn't pass validation. I simply repopulate the form with the entered values with errors highlighted, exactly what you would do without PRG. Only when POST is successful, I redirect browser to the GET page. In your case, you only need to have the username in the URL so you can display a personalized welcome page.

Yes, we will get double-submitting on failed forms but this turns out more desirable for our usecase. When user navigates back to the form, they will get the error again and resume their work. Due to the validation, there is no double-committing, that's the only thing we try to avoid.

ZZ Coder
I might have to settle with that, but if possible I'd like to do it my way :-p
alex
+1  A: 

Try Wicket - it does this by default.

CarlG
I've been researching Wicket... and it seems to be a bit heavyweight for what I want (just form handling), it doesn't integrate well with Spring, and I'm not fond of component-based web frameworks.I admit I do have probably unfeasible requirements. Ideally I'd just like a small component, something like commons-beanutils but without the suck.
alex