As zaccaria told you - this is really, really hard problem.
All because it clients (browser) specific case (mood) how it will process clicking on the Back button. I.e. if it will reload page from server / cache, if it will refill previously filled forms (some browser has such behaviour) etc. You haven’t even got sure if a JS / jQuery code included in such page will be re-executed (some browsers does not do this, when re-reading page from cache).
For example (a bit off-topic, but explaining the problem), if you use simple JS code:
for the link onClick event and click that link a few times, you will have a total mess in Firefox browsing history, as this browser is adding new position to history each time page is being reloaded (which IMHO is an absurd - this is still the same page and FF knows this, as it is responding for reload request; IE does not have such behaviour, if I’m not mistaken).
So, this example illustrates that there are many problems across browsers and this is one of biggest pains of web developers ever.
All I can recommend you here is to include your own back button, inside page content, and strongly advice your users (with clear, visible message) not to use browsers build-in back button - I seen such approach on some bank webpage and must admit that it is some kind of nice solution for this problem.
Thanks for all the replies. I’d prefer not to store variables in session, disable the Back button, or cause the Back button to given an alert. I want the Back button to do what it does by default (outside of the Yii framework); it delivers the page from the browser’s cache–with all of the form data intact.
Antonio, this looks promising:
Antonio > When I have to deal with multiple forms and the data is relevant to the next
Antonio > steps I do set systems that ‘hide’ but not ‘submit’ data until the confirmation occurs.
Can you be more specific, though? Are you simply saying the "action" method for the form is "get" rather than "post"?
Emily - one way possibly around this is to render the confirmation page in the same controller action and not redirect to a different action if the data passes validation. You must also ensure the form submits to itself, i.e. the form’s ACTION attribute should be blank or pointing to itself.
This way when you click the back button your form inputs should still be populated. I have a form that works exactly this way on one of my websites and I can confirm it does not erase the inputs upon clicking the back button (tested on IE8).
I assume at the moment your controller action redirects to another action - this way POST data is not carried forward in the headers.
When user clicks ‘confirm’ or ‘end’ or ‘submit’ at the end of the wizard, is actually clicking the button that submits the form at the first layer.
(please, refer to the links I posted on my previous response… if you have firebug installed, you will see that I actually ‘hide’ literally the information before I post final decision -payment gateway)
Thanks Antonio for all the suggestions! I’ll definitely have a look at how you implemented wizards. I have another open question on the forum – it deals more with temporarily enabling the browser’s caching, rather than a complex solution like wizards; it’s my first choice as I like to keep things simple, and I don’t like effectively disabling the user’s Back button:
If the perfect elegant solution arises, I’ll post it on that thread and this one. Thanks again!
Are you 100% sure that forcing pragma-cache in header will solve are your problems related to re-filling or not re-filling form contents after user click back button? As I recall from my earlier projects I had a few situations where keeping form contents after using back button was not handled properly and not related to cache as caching was turned off in browser in that particular situation.
Keep an eye of this problem, because even if you think it works now, it might sadly stop working in future. As I wrote above, browsers upon using next/previous buttons are really twisted organisms. I wouldn’t bet my life on it that filling form contents is only related to cache. Form autocomplete feature of browser or plugin has a lot to say in this situation, Beside, what would that browser do, if cache would be turned off? And it is being turned off among more and more users due to connections speed being faster (therefore leading people to desire of having always up-to-date content of viewed pages) and for the security reasons. Especially, when accessing pages in some multiuser places like airports, Internet cafes etc.
During last weekend, before I read your post, I was thinking about really crazy solution. Storing what user has entered in some temporal DB table, implementing AJAX function running in background and checking if form fields aren’t empty upon page load, refilling them if so and flushing DB temporal table, when user finishes whole process. But this is really hard to implement and what is more important - as I wrote earlier - developer can’t be sure if after using back button, browser will refresh page (some does not do this) causing onload function to fire.
Yes, I also thought of various insane solutions before realizing that programmers really are in love with complex solutions, but a simpler one is always superior.
Adding the headers has fixed the issue. The user can click the Back button and get the browser’s default behavior, which is to naturally cache pages. I add these headers ONLY when I want to explicitly grab pages from cache–which is very natural when someone is filling out a form.
I agree there’s a slight security concern – someone in an airport, etc. I guess I’m trusting my users are a wee bit savvier than that, and would know to remove all cached files if using a computer in a public place.
Antonio - that is a very good solution, however clicking the “back” button on the browser doesn’t take you back to a previous step, because it isn’t actually loading a new “page”. Is it possible to enable back button on browser for this type of form?