Wrox Programmer Forums

Need to download code?

View our list of code downloads.

Go Back   Wrox Programmer Forums > Web Programming > JavaScript > Javascript
Password Reminder
Register
| FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read
Javascript General Javascript discussions.
Welcome to the p2p.wrox.com Forums.

You are currently viewing the Javascript section of the Wrox Programmer to Programmer discussions. This is a community of tens of thousands of software programmers and website developers including Wrox book authors and readers. As a guest, you can read any forum posting. By joining today you can post your own programming questions, respond to other developers’ questions, and eliminate the ads that are displayed to guests. Registration is fast, simple and absolutely free .
DRM-free e-books 300x50
Reply
 
Thread Tools Search this Thread Display Modes
  #1 (permalink)  
Old April 8th, 2004, 11:22 AM
Authorized User
 
Join Date: Jun 2003
Location: Sheridan, OR, USA.
Posts: 53
Thanks: 0
Thanked 0 Times in 0 Posts
Default Page refresh, Back Button unhide hidden division

Hi:

I have a survey page that allows a user to provide contact information so that we can send him/her a token gift for participating. They also have the option to decline the gift and therefore don't provide the contact info.

By default, the survey loads as 'Accept' and the contact data controls visible.

Upon checking the 'Decline' radio button, the contact data controls are hidden. They are hidden by enclosing them within a <DIV> tag and using JavaScript to set the style to visibility='hidden'.

For the most part, this all works as expected. However, in testing the page in the 'Decline' mode, I find that if I hit the 'Refresh' button, or upon successful submission of the survey (which takes you to a 'Thank you' page, upon clicking the 'Back' button, the page will display with the contact data fields visible. I have already dealt with a similar problem with the 'Reset' button (via the document object model (DOM)) for the form

As I write this and think about it more, I'm coming to the conclusion that I need to access the Browser Object Model (BOM) and force it to hide that section.

I think I'm on the right path now, but if anyone sees that I'm going astray or simply has some information that I may find helpful, please feel free to respond.

Thanks,
JK
Reply With Quote
  #2 (permalink)  
Old April 8th, 2004, 06:13 PM
Friend of Wrox
 
Join Date: Nov 2003
Location: , , .
Posts: 1,285
Thanks: 0
Thanked 2 Times in 2 Posts
Default

Well, you have two choices in my opinion.

1) Disable the back button by excluding it in a window.open() call.

2) (The better way) Set a cookie when the user switches between decline and accept. Then, when the page loads, read the cookie. If it says decline, make the mode decline, and vice versa.

HTH,

Snib

P2P Member
<><
Reply With Quote
  #3 (permalink)  
Old April 9th, 2004, 11:54 PM
Friend of Wrox
Points: 3,558, Level: 25
Points: 3,558, Level: 25 Points: 3,558, Level: 25 Points: 3,558, Level: 25
Activity: 0%
Activity: 0% Activity: 0% Activity: 0%
 
Join Date: Jun 2003
Location: California, USA
Posts: 996
Thanks: 2
Thanked 11 Times in 11 Posts
Send a message via Yahoo to melvik
Default

I believe using expire in [u]ASP </u>is better way for ur goal.!!!

Always:),
Hovik Melkomian.
Reply With Quote
  #4 (permalink)  
Old April 10th, 2004, 03:01 PM
Authorized User
 
Join Date: Jun 2003
Location: Sheridan, OR, USA.
Posts: 53
Thanks: 0
Thanked 0 Times in 0 Posts
Default

Hi:

Thanks for the responses.

So, is the following a true statement?

DHTML changes to a page, implemented by Javascript code, are NOT maintained anywhere? So a page Refresh will refresh the HTML controls and values correctly, but none of the DHTML changes that may have occurred in setting the controls to their current values.

That is the impression I am left with in reading these responses, together with my observations prior to initiating this thread, and the results of a couple of tests I've run since your responses.

So, if you want to retain the DHTML state through a refresh (or Back button), you'd need to somehow store the sequence of changes by the user?

When one clicks on the Refresh button (or Back Button), what actually happens? Does a refresh actually re-load a page? It must not, otherwise changes to controls would not be maintained. Would a refresh (or back button) actually read a cookie if there is a cookie reading routine in the page?

Sorry for all the additional questions. I have a lot of useful information and I'm just trying to connect them together.

Hovik:

I didn't know about the Expires (and ExpiresAbsolute) property until I read your reply. Interesting, I can see where that can be useful. However, does that mean if they hit the Refresh button that the page would reload they'd be starting the survey all over again?

Thanks again,

JK
Reply With Quote
  #5 (permalink)  
Old April 10th, 2004, 03:17 PM
Friend of Wrox
 
Join Date: Nov 2003
Location: , , .
Posts: 1,285
Thanks: 0
Thanked 2 Times in 2 Posts
Default

Changes made by DHTML are not retained when a page refreshes, except in some special cases such as when certain form elements are changed.

The only way I know of for JavaScript to pass values from one page to the next (without the aid of a server language) is by cookies.

When you click the Refresh button, the browser re-requests the page from the server. When you click the Back or Forward buttons, the browser looks in the temporary cache of resently visited files (unless the headers of that page told the browser not to).

I don't really understand your last question about cookies. I will answer guessing what you're talking about: when the Back, Forward or Refresh buttons are pressed, all JavaScript is run again (including cookie-related code).

Let me explain why cookies are probably a better solution than excluding the Back button. On most browsers, you can right-click and select Refresh from the drop-down menu. Also, recent keyboards often have web control buttons such as Refresh. If you store the values in a cookie, as long as the user has JavaScript available (which I'm fairly sure he/she has to, since your page uses quite a bit of it), the JavaScript will read the cookie for either decline or accept values.

Let me know if there are more questions,

Snib

P2P Member
<><
Reply With Quote
  #6 (permalink)  
Old April 10th, 2004, 03:32 PM
Authorized User
 
Join Date: Jun 2003
Location: Sheridan, OR, USA.
Posts: 53
Thanks: 0
Thanked 0 Times in 0 Posts
Default

Hi Snib:

I agree that diabling the Back button is undesireable, but my reason is just as simple as the fact that it is a user-unfriendly thing to do. I wouldn't expect the button to be disable by an application and I wouldn't appreciate it if it happened to me. Just from a UI point of view, there is nothing to recommend it.

You may not have understood my question about cookies, but I think you answered it.

The partial statement '... as long as he/she has JavaScript available...' confuses me a little. Isn't Javascript always available from the client browser? If not, that comes as a surprise to me, and not a good one. Also if not, is there a test for availability?

Thanks again,
JK
Reply With Quote
  #7 (permalink)  
Old April 10th, 2004, 03:46 PM
Authorized User
 
Join Date: Jun 2003
Location: Sheridan, OR, USA.
Posts: 53
Thanks: 0
Thanked 0 Times in 0 Posts
Default

Hi Snib:

Another question.

The partial statement:

"...except in some special cases such as when certain form elements are changed."

Does that mean use of properties like innerHTML and outerHTML, things that actually change the content of a page?

I ask because, if so, that would mean that as part of 'hiding' the <div> tag contents, I could also change the controlling radio buttons HTML to specify "CHECKED" or "" as appropriate.

Sound reasonable?

Thanks,
JK
Reply With Quote
  #8 (permalink)  
Old April 10th, 2004, 03:51 PM
Friend of Wrox
 
Join Date: Nov 2003
Location: , , .
Posts: 1,285
Thanks: 0
Thanked 2 Times in 2 Posts
Default

All the browsers I can think of have JavaScript available. I guess I worded it wrong. What I meant was '... as long as he/she has JavaScript enabled ...' becuase in all browsers I know of you can disable JavaScript, usually to avoid popups or something like that.

As for testing if it's available, that's easy. Make the page you want to test on have this JavaScript in it:
Code:
window.location = 'javascript_enabled.php';
replacing 'javascript_enabled.php' with your own page that is made for JavaScript. Also include a meta tag like this:
Code:
<meta http-equiv=refresh content=2;url=javascript_disabled.php
replacing 'javascript_disabled.php' with a page that says "You must enable JavaScript to continue".

Here's the logic behind it:

The JavaScript redirect can't redirect if JavaScript is disabled. Setting the meta tag refresh delay to 2 seconds gives the browser a moment to run the JavaScript, and if it hasn't redirected in 2 seconds, the meta tag will send you to the page that notifies about enabling JavaScript.

However, this probably won't be extremely neccessary, depending on how many people are taking this test. If you have half the world on there, there's bound to be some without JavaScript enabled. But if the number testing is not that many, you shouldn't have a big problem.

Let me know if you have any more questions, I'll be glad to answer them.

Snib

P2P Member
<><
Reply With Quote
  #9 (permalink)  
Old April 10th, 2004, 03:54 PM
Authorized User
 
Join Date: Jun 2003
Location: Sheridan, OR, USA.
Posts: 53
Thanks: 0
Thanked 0 Times in 0 Posts
Default

Hi Snib:

Never mind.

I just remembered that one of the tests that I ran used 'innerHTML' (added a text box when a checkbox was checked) and refreshing the page dropped the text box. So, based on that result, it's not reasonable.

JK
Reply With Quote
  #10 (permalink)  
Old April 10th, 2004, 03:56 PM
Friend of Wrox
 
Join Date: Nov 2003
Location: , , .
Posts: 1,285
Thanks: 0
Thanked 2 Times in 2 Posts
Default

I don't think innerHTML and outerHTML stay the same. I'm not sure. You could test it though. I was talking more of when you change the value of a form element such as making the value of a text input say something when you hover over a certain DIV, or something like that.

I didn't include this in my last post because we posted within seconds of each other, and I didn't see your last one until now.

Once more, notify me if you need more info. I'm glad I can help.

Snib

P2P Member
<><
Reply With Quote
Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Preventing page refresh from asp.net button hericles ASP.NET 1.0 and 1.1 Professional 2 October 8th, 2008 04:29 PM
don't want the page refresh on button click swati_joshi ASP.NET 1.0 and 1.1 Basics 4 July 31st, 2006 04:37 AM
Refresh Page when User Clicks on Back Button testsubject Visual Studio 2005 1 June 26th, 2006 03:46 AM
refresh the page when using back button hastikeyvan Classic ASP Professional 1 May 12th, 2006 11:08 AM
history.back or hitting the back button won't work lian_a Classic ASP Basics 4 July 29th, 2004 12:14 AM



All times are GMT -4. The time now is 02:41 PM.


Powered by vBulletin®
Copyright ©2000 - 2019, Jelsoft Enterprises Ltd.
© 2013 John Wiley & Sons, Inc.