form-post and back-arrow OK with action.php inbetween

by Derek Sivers

It's bad bad bad when you use form method="post" and your user hits the back-arrow afterwards...

... unless you use an approach I knew was possible, but never tried before a project I'm doing now.

Goes roughly like this:

-------------- someform.html -----
<form action="action.php" method="post">
<input type="hidden" name="action" value="delete" />
<input type="hidden" name="id" value="12345" />
<input type="submit" name="submit" value="delete this" />
</form>
-----------------------------------------

-------------- action.php ---------
switch($_POST['action']) {
case 'delete':
$id = intval($_POST['id']);
$db->query("DELETE FROM something WHERE id=$id");
header('Location: menu.php');
break;
case 'add':
# blah blah - your "add" actions stuff here
header('Location: newentry.php');
break;
}
-----------------------------------------


Have *ALL* forms on all pages all posting to the same action.php page, which has a switch/case looking for the correct action, then using HTTP header-location to send them off to the next page. If they use their back-arrow now, no problem! It will never re-post the form.

(As a variation on this, I guess you could have lots of little PHP pages catching lots of form-post actions, then header-redirecting, but I was just trying to keep them all in one place.)

Only problem I had with this approach is that I like to alert the person who did some action that the action has been done! I added an Alert class with just two public methods: add and show. (Private methods are load and save, used at __construct and __destruct, respectively.) Now your action.php file can add an alert to the Alert class, then header-redirect off to any page you'd like, as long as the destination page has Alert::show where you want the saved alert to appear.

Anyway - I'll bet this approach has been done before in a way I hadn't thought of, but this is how I'm doing it for now, and I like the way it works so far. I'd love to hear from anyone else with a different approach to solving the form-post back-arrow conflict.


different approach to solving the form-post back-arrow conflict?


3 Comments

ckeat
2004-12-07 00:52:32
aka Redirect After Post
This topic has been heavily discussed on tss, known as Redirect After Post


And quite frankly any web application framework that doesn't enforce or help do this should be spanked.

ivarley
2004-12-07 07:10:31
A twist
On an application I worked on a few years back, written in ASP, we started with that idea (thinking of the action pages as "router" pages). Our big breakthrough came in shifting our thinking about it a little bit, and seeing those pages as "Event" pages. I.e. the function that gets called by the switch statement is something like "SaveButton_OnClick". That way it's very obvious from the coding point of view what action you're writing code to. We went one step further and actually had the name of the button automatically determine which function gets called (by attempting to evaluate an expression using the name of the button plus "_OnClick"). That eliminated the nasty switch statements, and gives you the opportunity to do something sensible if they click a button that has no handler.


Finally, we also ended up breaking the pages up into discrete "Event" pages for each system page ... so you'd have a "ItemDisplay_Event" page, a "Preference_Event" page, etc. That's helpful if your one action page gets too big.

shiflett
2004-12-07 17:09:57
Page Has Expired
It sounds like you might find this article helpful:


http://www.phpmag.net/itr/online_artikel/psecom,id,637,nodeid,114.html