form-post and back-arrow OK with action.php inbetween
by Derek Sivers
... 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" />
-------------- action.php ---------
$id = intval($_POST['id']);
$db->query("DELETE FROM something WHERE id=$id");
# blah blah - your "add" actions stuff here
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?
aka Redirect After Post
This topic has been heavily discussed on tss, known as Redirect After Post
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.
Page Has Expired
It sounds like you might find this article helpful: