javascript for form to retain details when back buttoning

mattys · Mar 16, 2005

Hi

I have a html form here

http://www.saltrock.com/login/user.asp,

on an ASP page.

If you fill the form in, hit submit, then have to hit the back button to ammend the form, say, to use a different usename, or password, previously input details have dissapeared. Obviously this is a right pain.

Does anyone know of a bit of Javascript to stop this happening, so details are kept on the form, except where the details have to be ammended, for example, as above.

I have already submitted to the javascript forum, and had the replies in quotes below:

QUOTE 1
"I dont think Javascript can help. It works within the current page. Every request for a new page starts afresh. Submit and Back are requests for new pages. Not new to the person maybe, but new to the browser.

So you have to catch the form data when the form is submitted the first time. You must keep this data in session variables. And you must keep track of the fact that the form has been submitted. I dont know that you can keep track of whether the form has been requested by clicking the Back button specifically. But you can arrange the process in user.asp to assume that a subsequent request results in displaying the form with the fields filled with the data in the session variables."

QUOTE 2
"i believe it has something to do with browser cacheing. i know in php there is a single line of code that you can put on the top of your php page to enable this.

possibly, something similar exists in asp.

javascript is not the ideal solution."

Anyone got any ideas?

Matt

bslintx · Mar 18, 2005

I don't now how you could relay the values in (asp) w/ the back button but you could create a form "back" button on the second page to redirect to original page and populate that form w/ the values just sent by "postbacking" .... In your form fields for example:

form.asp

Code:

<html>
 <head>
</head>
<body>

<%
   email = Request.Form("email")
   submit = Request.Form("submitEdit")

   If submit <> "" OR submit = "" Then  
%> 

 <form action="page2.asp" method="post">
  Email: <input name="email" size="20" maxlength="20" value="<%=email%>">
  <input type="submit" name="submitForm" value="Submit">
 </form>

<%
  End If
%>

</body>
</html>

page2.asp

Code:

<html>
 <head>
</head>
<body>
<p>
   Thanks for submitting. Need a quick change? Please click button.
</p>

<%
   email = Request.Form("email")
   submit = Request.Form("submitForm")
%>

 <form action="form.asp" method="post">
  <input type="hidden" name="email" value="<%=email%>">
  <input type="submit" name="submitEdit" value="Edit">
 </form>
</body>
</html>

trollacious · Mar 18, 2005

If you store the information in cookies, you can use Javascript to load the form elements from that when the page reloads.

Lee

a6m1n0 · Mar 18, 2005

Why not use a session variable(s)?

session("username")=request.form("username")
session("password")=request.form("password")

It wouldn't matter what page you were on, although cookies (something beyond session cookies) would work equally as well.

-a6m1n0

"Don't try to reinvent the wheel." -My HS FORTRAN Professor

bslintx · Mar 20, 2005

What if cookies are disabled on user machine? Wouldn't that affect session object as well sense it requires cookes?

onpnt · Mar 20, 2005

data area backend is the only true method to retaining the values while not having to concern yourself with how the user has the viewing applications setup.

Yes. Cookies off = no session state.

Try a flat file or even as scary as it sounds going with a small dynamic table structure in a DB would be nice and quick.

___________________________________________________________________
_{onpnt.com

SELECT * FROM programmers WHERE clue > 0

(0 row(s) affected) -->faq333-3811}

a6m1n0 · Mar 20, 2005

@bslintx

What if cookies are disabled on user machine? Wouldn't that affect session object as well sense it requires cookes?

Yes, it would affect using session()'s as onpnt has pointed out.

The question is how much should you expect from your potential user? Shouldn't you expect a user to at least *Not* disable session cookies? Well of course you should expect them to at least accept session cookies!

Think about it like this: If a user is coming to your site to login after filling out a form to receive an email, then the user that has session cookies disabled will *Have* to enable session cookies to login, unless you plan to spend alot of time getting around using session()'s.

If it were me I would save myself some coding time and use a function to verify cookies are enabled in the browser, and if not alert the user upon loading the form in the client browser that:

"This web page requires that your browser accept Session Cookies to successfully register. Click here to get help on enabling Session Cookies in your web browser. Click here to view our Privacy Policy."

An example of how to do this HERE.

If the user browsing to your form receives this information and wants what registration has to offer, they *WILL* enable session cookies, especially if you tell them how to do it and gurantee that you are not invading thier privacy. That's all they care about anyway and is 9 out of 10 times the reason cookies are disabled at all.

Yes it's a gamble that Joe Smith might not register at your site, but the other 9 users probably will. Writing up a Privacy Policy and doing a few step-by-step guides for enabling session cookies for IE and FireFox will be much simpler to implement than expecting every possible move your user *MIGHT* make and gives you a standardized way of handling this situation with other areas of your site where you might expect session cookies to be enabled.

Because I am not an authority on statistics regarding what percentage of users do versus don't have cookies enabled in thier browser, I consulted Google.

The most conservative estimations on how many users have cookies enabled come from university and research sites. These are naturally also the most trust-worthy statistics: "90% of users have cookies enabled permanently on their browsers"
(SOURCE: School of Information and Computer Science, University of California, Irvine, "Modeling the Internet and the Web: Modeling and Understanding Human Behavior on the Web"

Reference

I hope you find this post helpful.

-a6m1n0

"Don't try to reinvent the wheel." -My HS FORTRAN Professor

bslintx · Mar 21, 2005

hey a6m1n0,

didn't mean to ruffle feathers...just inputed insight on the situation;-) I personally wouldn't worry about using cookies since the backend can do the work just fine...if the query finds that the username or password already exists...then postback the info and redirect the variables to original page. Yes, many use cookies and they are a saving grace for the most part...but i have to agree w/ onpnt that the backend is the way to go...ON THIS SITUATION...there is a time and place for cookies...but I don't think it's necessary here...btw thanks for the stats!

BSL

a6m1n0 · Mar 21, 2005

I'm sorry if I gave you the impression my 'feathers' were 'ruffled'. I was just pointing out that expecting a user to have cookies enabled is not expecting to much, and that this is a viable, working, well documented way to maintain user state across all areas of a website.

Just additional info to help save a coder some time is all it was meant to be. Glad you like the stats!

-a6m1n0

"Don't try to reinvent the wheel." -My HS FORTRAN Professor

Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

javascript for form to retain details when back buttoning

mattys

Programmer

bslintx

Technical User

trollacious

Programmer

a6m1n0

Programmer

bslintx

Technical User

onpnt

Programmer

a6m1n0

Programmer

bslintx

Technical User

a6m1n0

Programmer

Similar threads

Part and Inventory Search

Sponsor