Forums

This topic is locked

Caching Data in Forms

Posted 18 Dec 2002 23:05:46
1
has voted
18 Dec 2002 23:05:46 A. B. posted:
I have two pages, page1.asp and page2.asp. Page1.asp contains a form with textboxes, list/menus, and radiobuttons. The list/menus are pulling the values from a SQL Server 7 database.

Page2.asp collects the data and displays it for the user to verify. If the user wants to make changes, he can press "Back" and return to page1.asp. But when I do this the data that I had entered is gone.

How can I retain the data in the completed fields?

Thank you in advance for your help.

Andrea

UD4/SQL Server 7

Replies

Replied 19 Dec 2002 10:16:03
19 Dec 2002 10:16:03 Lee Diggins replied:
Hi Livvy,

it sounds as if you are explicitly calling the page rather than navigating back via history.

Does the page work when you use the browser 'back' button?
Are you using your own 'back' button and is this the one that fails?

If the answer to both the questions are 'Yes' then you need to change the code on your own 'back' button to:

<pre id=code><font face=courier size=2 id=code>javascript:history.go(-1);</font id=code></pre id=code>

If the answer is 'No' then a lesson in handling 'Session State' is in order....

Hope this helps.

How about the Yaromat and radio button post, did you understand my reply, did it work - it would be nice to know?



Digga

Sharing Knowledge Saves Valuable Time!!!
Replied 19 Dec 2002 14:59:07
19 Dec 2002 14:59:07 A. B. replied:
Hi, Digga. To answer your two questions:

Does the page work when you use the browser 'back' button? Yes it works when the browser "back" button is pressed.

Are you using your own 'back' button and is this the one that fails? Yes it fails when my own "back" button is pressed even though I am using &lt;a href="javascript:history.go(-1);"&gt;back&lt;/a&gt;.

You mentioned "session states." I'm sorry but I am unfamiliar with this. Is this the same thing as session variables? If so, how do I start using session variables?

In response to your inquiry about the Yarmot check form radio button problem: All of the radio buttons do have the same name but different values. I have tried smaller groups but it is still confusing to the user because the user thinks he has to click a button in each group to get rid of the error messages. I am also passing the clicked radio button value to a page2.asp for verification. Then page2.asp has respective hidden fields so I can then pass that data on to page3.asp and insert it to the database. So to answer your question, I do not a solution for that check form problem.

I hope I'm making some sense here. <img src=../images/dmxzone/forum/icon_smile.gif border=0 align=middle>

Please tell me about session states. I appreciate your help so much. Thanks!

Andrea
Replied 20 Dec 2002 00:47:21
20 Dec 2002 00:47:21 Lee Diggins replied:
Hi Livvy

<b>Session State</b>
Webservers are rather dumb creatures, they are 'Stateless'. They serve you once and then forget who you are, and they don't care. Session state is about getting the server to <b>remember</b>. You do this already when you submit a form either using POST ('Form') or GET ('QueryString'). There also other ways of maintaining state - Session Variables being one of them, databases another.

You need to decide how you are going to reference these parcels of information. If you're using POST, then the next page can read the values from the Forms Collection, GET reads the QueryString (everything after the ? in the URL).

Livvy, I've run out of time, I've accidentally (like one does), hit the wrong key on the keyboard (ALT+LEFTARROW), would you bloody believe it. So came back to this page only to find a nice blank form, rather than the lesson on 'State', and so started again.

I'm off to bed.



Digga

Sharing Knowledge Saves Valuable Time!!!
Replied 20 Dec 2002 01:21:01
20 Dec 2002 01:21:01 A. B. replied:
Hi, Digga. Thanks for the information about session states, that makes a lot of sense.

Let me see if I can explain better what I'm trying to accomplish with the two pages.

Page1.asp - users enter their information, list/menus are dynamic pulling values from the db. When the user completes the form, presses Submit, the page is sent to Page2.asp using the "post" mthod.

Page2.asp - users verify their information, which is displayed as request.form objects (no textboxes, list/menus, etc.). If the user is satisfied with the data, he presses Submit and is taken to a third pages which inserts the information to the db.

The problem I've having is when the user is not satisfied with his entered informaiton and chooses to change it. To do this, the user presses a "back" button and is returned to Page1.asp, which displays his entered information (and list/menus are pulling values from the db).

Does that make any sense? Is this where session states are used?

Thanks,

Andrea
Replied 20 Dec 2002 11:08:05
20 Dec 2002 11:08:05 Lee Diggins replied:
Hi Livvy,

It's as good a place as any, although you can use them anywhere and at anytime.

I’m going to continue with the basics of maintaining state, the advanced people out there who read this post need to take this with a pinch-of-salt as I’m trying to KISS (Keep It Simple Stupid).

There are a number of objects you can use as a web developer to maintain state and the two state types are Application and Session.

<b>Application State</b>
You would use this when you need to access Website or Application wide information that’s available to all, a connection string for example or maybe your website counter or your web apps name, you’ll be surprised what people store in the Application Object.

The lifetime of the Application variable is normally from the first request on a web server until the web server service is stopped, the hardware rebooted or the variable is destroyed, however, the values can change throughout it’s lifetime, the website counter being a good example here.

<b>Session State</b>
Applies to the individual user connected to the web server, you can have many connections to different users, however, all the users have their own Session which lasts for the duration of their visit. The session is destroyed when the user is no longer connected. You could create a Session Variable when a user logs in successfully with the UserID or their access level. This makes things simple later on when retrieving data based on the users ID or access level and remember you can access these variable anywhere in the application at any time during the ‘Session’.

Below is a list of objects that will help you ‘Maintain State’:

Application Object – application variables
Session Object – session variables
Forms Collection – form items submitted using POST
QueryString Collection – form items submitted using GET
Cookies
Database tables
hiddentext boxes – a real favourite of many

Livvy, you will need to decide how you are going to maintain state for this form, you’ll retrieve the information from the Forms Collection and put it somewhere, the session variable route being the one you’ve asked about.

Create your session variables on the second page using unique and meaningful names

<pre id=code><font face=courier size=2 id=code>Session(“mySessionData” = Request.Form(“txtBoxName”</font id=code></pre id=code>

Write code in at the top of your form page to check if the session variable contains any data and if it does, populate the form with the stored data rather than presenting a blank form. You will need to destroy the session variables somewhere, on the 3rd asp page is good. The main problem with session variables is managing them, if your user is on page 2 and doesn’t decide to submit or go back to the form but instead navigates to another page, the session variable still has data stored inside it and when the user comes back to the form, the data loads inside the form again.

Destroy your session variable:

<pre id=code><font face=courier size=2 id=code>Set Session(“mySessionData“ = nothing
Session.Contents.Remove(“mySessionData”</font id=code></pre id=code>

I can go on and on (like I have already) about session variables, I like them, however, there are a lot of developers out there who do not advocate the use of them.

Cookies would also be good, setting an expiry date of 5 or 10 minutes in the future.

It all depends on your web application, so give it some thought, especially about managing the variables if you go down that road.

Good Luck!




Digga

Sharing Knowledge Saves Valuable Time!!!
Replied 20 Dec 2002 11:13:59
20 Dec 2002 11:13:59 A. B. replied:
Digga, thank you so much for all of your help and patience! <img src=../images/dmxzone/forum/icon_smile.gif border=0 align=middle>

Andrea
Replied 21 Dec 2002 03:42:22
21 Dec 2002 03:42:22 Dennis van Galen replied:
I thought MacroMedia was all about Keeping It Stupid Simple...

with regards,

Dennis van Galen
DMXzone Manager

Extension, Tutorial and FAQ's Manager

Hungry ? <a href="www.thepattysite.com/dwg_main.cfm" target="_blank">Visit
Dreamweaver Gourmet</a>
Replied 23 Dec 2002 10:06:13
23 Dec 2002 10:06:13 Lee Diggins replied:
Hi djvgalen,

LOL, if only!!!

I didn't intend to go on so, and appologies to Livvy, yourself and any others reading this thread.

My intention was to educate and not to blow my own knowledge trumpet. I do not seek an audience or to inflate my ego but to pass on information about Maintaining State, as this is one of the most important things to understand when dealing with web servers.

I have found at my own cost that understanding state can resolve so many problems very early on.

I will endeavour to KISS in future, point here click there etc.

Forever KISSing.



Digga

Sharing Knowledge Saves Valuable Time!!!

Reply to this topic