incrediBILL
msg:4219359 | 5:08 pm on Oct 20, 2010 (gmt 0) |
One simple way to stop it is to open that form in a new window or tab, therefore there is no back button on the window/tab with the form, and they can still browse the website in the previous window/tab.
Low tech, 2 second fix.
|
mightymouse3062
msg:4219402 | 7:04 pm on Oct 20, 2010 (gmt 0) |
I like that fix and it works well, however if they refresh the page all of the information is lost as well.
In knowing some of the people that will be filling this form out... it needs to be as user friendly as possible.
Thanks,
Mike
|
Dijkgraaf
msg:4219438 | 8:06 pm on Oct 20, 2010 (gmt 0) |
1) When you open up the new window, do it without the toolbar.
2) Trap the F5 key and a few others, and don't allow it to refresh (see below)
Otherwise you will have to save the state of the page (search for view state) and handle when you want to when it should use the previously entered and when is should be a fresh form.
Sample JavaScript
document.onkeydown = trapKey;
function trapKey(evt) {
evt = (evt) ? evt : window.event;
if (evt) {
if (evt.keyCode == 8 && (evt.srcElement.type != "text" && evt.srcElement.type != "textarea" && evt.srcElement.type != "password")) {
// When backspace is pressed but not in form element
cancelKey(evt);
}
else if (evt.keyCode == 116) {
// When F5 is pressed
cancelKey(evt);
}
else if (evt.keyCode == 122) {
// When F11 is pressed
cancelKey(evt);
}
else if (evt.ctrlKey && (evt.keyCode == 78 || evt.keyCode == 82)) {
// When ctrl is pressed with R or N
cancelKey(evt);
}
else if (evt.altKey && evt.keyCode==37 ) {
// stop Alt left cursor
return false;
}
}
function cancelKey(evt) {
if (evt.preventDefault) {
evt.preventDefault();
return false;
}
else {
evt.keyCode = 0;
evt.returnValue = false;
}
}
|
rocknbil
msg:4220431 | 3:56 pm on Oct 22, 2010 (gmt 0) |
| if they click the back button to possibly go back to edit the page all of the data disappears. I am not sure how to fix the problem. |
|
This is due to, most likely, your server configuration, it's not allowing caching. Especially true of PHP apps that generate the forms. Rather than fix it with Javascript or patches in your programming you might look into the configuration of the server, I see it a lot and it's rather annoying. :-)
also check the actual HTML headers, make sure there's no no-cache, etc. being output in your pages.
|
mightymouse3062
msg:4220601 | 8:20 pm on Oct 22, 2010 (gmt 0) |
How would I check the headers to see if it is allowing caching?
Thanks,
Mike
|
rocknbil
msg:4221033 | 7:26 pm on Oct 23, 2010 (gmt 0) |
I meant the headers in your page output (but don't chase it too hard, it's not likely that, it's more likely the http headers from the server.)
<meta http-equiv="Pragma" content="no-cache">
<meta http-equiv="Cache-Control" content="no-cache">
<meta http-equiv="Expires" content="Sat, 23 Oct 2010 00:00:00 GMT">
|
phranque
msg:4221193 | 6:17 am on Oct 24, 2010 (gmt 0) |
| How would I check the headers to see if it is allowing caching? |
|
Live HTTP Headers :: Add-ons for Firefox:
https://addons.mozilla.org/en-US/firefox/addon/3829/ [addons.mozilla.org]
|
kaled
msg:4221373 | 8:42 pm on Oct 24, 2010 (gmt 0) |
I haven't looked closely at what you're trying to do but it looks like simple form validation - so why not use javascript? However, assuming there's a good reason...
Relying on the back button is always going to be iffy. Your form processor should always move forwards - if there's an error on the page it should be reshown with all fields completed (but still editable) and with the error(s) highlighted.
If you're prepared to use javascript, why not create one huge page with tabs and validate each tab when the user attempts to move on. I've never tried anything like this, but it should be possible to place multiple tabs within a single form so that all the data can be submitted in one go at the end.
When filling in complex forms, people often like to be able to flip back and forth between pages so this approach will be far more user-friendly.
Kaled.
|
milosevic
msg:4221579 | 12:36 pm on Oct 25, 2010 (gmt 0) |
I like kaled's idea, I feel this is the best way to design complex forms with currently available technology.
Is is possible to pop up a confirmation box on refresh/back e.g. "are you sure you want to leave this page?" - or is that something that is done by user-agents e.g. Firefox automatically?
|
mightymouse3062
msg:4221618 | 2:47 pm on Oct 25, 2010 (gmt 0) |
Good Morning,
I have the application that a user fills out. I have it broken down into several blocks of information and when the user clicks on continue it validates everything via javascript. From there, after all of the fields are validated, it goes to a confirmation page that displays all of the information the user just entered and has a "disclaimer" message. When they click on agree it takes the data, puts it into a database, and using TCPDF creates a pdf of the application and emails it.
The problem is when I am on the first page filling the form out and I click refresh all of the data disappears. Same as after I click continue to the second page (where it displays all of the information) and I click the back button (possibly to change something entered), the data disappears.
So, I added the code
<meta http-equiv="Pragma" content="no-cache">
<meta http-equiv="Cache-Control" content="no-cache">
<meta http-equiv="Expires" content="Sat, 23 Oct 2010 00:00:00 GMT">
and the problem still existed (I changed the expires date to 2 days in advance as well).
I tried this on another server, that I have never had a problem with loosing the data, and the problem still exists. If I enter data directly into the file where the form is stored, there is no problem with keeping the form data. If I have it included in another file, the data disappears. I am using the PHP require_once() function to include the file inside another file.
On a side note, somehow I managed to mess up the javascript which is causing some problems. A few people have been able to submit the form, even with all of the validation checks I did in javascript, with bad data. I have not been able to duplicate the problem... can someone look at the code and see if I missed something? A copy of the javascript is at [gta-nation.com...]
I like kaled's idea as well and to add to it, if I cant get whatever problem that is causing the data not to stay automatically, to change where the refresh and back buttons and send them to some "processing" page that will put the data into a session or whatever form page can read and input the data.
This all seems complicated and possibly going to cause more problems... is there a simple solution to keeping the data in the page?
Thanks a lot,
Mike
|
kaled
msg:4221659 | 4:05 pm on Oct 25, 2010 (gmt 0) |
<meta http-equiv="Cache-Control" content="no-cache">
|
|
I think caching must be enabled not disabled. Also, rather than using <meta http-equiv> use the the http headers directly - since you're using php, that should not be a problem.
Behaviour could be browser-dependent - I certainly would not want to rely on behaviour that's not absolutely specified somewhere in black and white (but maybe it is).
Kaled.
|
rocknbil
msg:4221680 | 4:55 pm on Oct 25, 2010 (gmt 0) |
Right mightymouse, I meant that make sure that's NOT there - those will prevent caching. Sorry if it confused you.
|
mightymouse3062
msg:4221736 | 6:37 pm on Oct 25, 2010 (gmt 0) |
Not a problem.
I have been working on this a bit more and its really annoying me that this problem is happening... so I started stripping code and it turns out I stripped it down to I have 2 files that are the exact same code.
[gta-nation.com...]
[gta-nation.com...]
application.php keeps the data if it is refreshed without a problem. index.php does not. I checked the permissions for both of the files and they are the same at 0644. Both folders (campstaff & pages) have permissions of 0755.
So, to try and figure out where the problem lies, I opened the index.php file and saved it as form.php and it works without a problem. I have cleared all of my browser cookies, cache, etc multiple times.
Any thoughts on why index.php is causing the problem?
Thanks,
Mike
|
milosevic
msg:4224825 | 12:58 pm on Nov 1, 2010 (gmt 0) |
I can only image that since changing the filename (with no other changes) fixed the problem, that directory index files are being treated differently in your server setup (ie httpd.conf)
|
mightymouse3062
msg:4224829 | 1:08 pm on Nov 1, 2010 (gmt 0) |
Good Morning,
Since this is a shared host, I dont have direct access to the server setup. How would I figure out what it is configured as and then go about changing those settings?
Thanks for your assistance,
Mike
|
|
