|Need advice: Global or Session variables|
for a multi-page reservation sequence
| 6:59 am on Mar 15, 2006 (gmt 0)|
Okay, the senerio is like this (and probably very familure):
1. User wants to make a room reservation
2. They click on the reservations page of this site I'm working on.
3. They fill in their personal details and accommodation requierments in on the form and click submit
4. They are displayed with a page where they can review all of their details they've input in the previous page
4a. if they want to change any of their details, they click the "Change Details" button and they are sent back to the reservation form page (all information they've alredy input is re-loaded into the proper form fields)
4b. If they're ok with their details, they click "Make Reservation". All of the information in the Reservation form is then dumped into a DB table and we're finished.
There's the basic workflow.
The core question is this: I can't use regular variables to retain info in Step 3 cause they vaporize when the "Review Details" page is loaded (step 4). So, what's preferrable to use to keep these details "alive" until the user clicks the Make Reservation button in step 4b? a bunch of global variables, or a session variable array?
I've never used globals or sessions before, but I understand that they do persist from page to page, and that they can also be cleared/distroyed at the end of this process.
Sorry for the long explaination, but I wanted everyone to really understand what I'm trying to do.
All advice greatfully appreciated.
| 1:01 pm on Mar 15, 2006 (gmt 0)|
Sessions should work
Here is how to:(Example using password and username)
Could be any values
session_start();// this goes on top of page
$username = $_POST['username'];
$password = $_POST['password'];
$_SESSION['username'] = $username;
You may have that type of script on any page where you need to pass those values through sessions
However only the originating page bears that above code
To pass values on other pages use
From the very top of your script
// and simply those:
if you need more persistence
you could feed a temp table
then when the input is no longer needed clean the temp table after loading in your main table the needed values.
| 1:17 pm on Mar 15, 2006 (gmt 0)|
Beware with session variables, I've found that if a variable is set on page 1, then the user clicks through to page 2 and the variable is set to another value, you have to be very careful of the back button. In the scenario above, if the user clicks the back button to page 1, the session variables are reset to how they were on page 1.
I would give the user a UID, then populate a temp table at the top of step 4. Make sure step 3 checks for the UID in the temp table in case the user clicks the back button. When the user confirm in step 4, populate your permanent table
| 7:47 pm on Mar 15, 2006 (gmt 0)|
you should always use session over globals... To fix some of the 'back button' problems, i sometimes use a seperate session variable that keeps track of the stages that the program might/should be in, and then you can combine them in with your logic to make sure people are seeing that right things at right time... Switches are good for that stuff too.
| 1:03 am on Mar 16, 2006 (gmt 0)|
Thanks for everyones advice. Due to the Sessions/back-button issue mentioned, I guess a temp table is probably the way to go.
Although what if the user closes the browser, or the power goes out (as it ALWAYS does here in the Philippines) unexpectedly. Then I'd end up with a bunch of stuff in a temp table unless I wrote something else to clear it out.
Hummm. Maybe using a seperate session as vacorama suggested would be a way to get around the temp table issue. Our perhaps I could just check to see if a session is already active if a user "back-buttons" to the first page?
| 12:50 pm on Mar 16, 2006 (gmt 0)|
Back browser problem
I used in a similar case to also write the same session to a dupli_page
that is never called upon but exists
page_a starts the session, by script definition the info is passed to page_b.
Then we are back browser button concerned
so by the same token write the same session to a dummy page: page_c
since the page_c is never called you can still grab that session for the duration of the user browsing on site time.
in our PHP forum look for the "bag of tricks"
there is info about what you need: TRANSACTION
and do a search for: table, database and transaction in the same terms.
| 4:41 am on Mar 17, 2006 (gmt 0)|
Henry-O: Thanks, I'll take a look.
| 2:48 pm on Mar 18, 2006 (gmt 0)|
|Beware with session variables, I've found that if a variable is set on page 1, then the user clicks through to page 2 and the variable is set to another value, you have to be very careful of the back button. In the scenario above, if the user clicks the back button to page 1, the session variables are reset to how they were on page 1. |
I'm not sure why the should be any issues with the back button. I'm assuming that you have the following scenario:
Page1 has a form that gets submitted and then page2 checks to see if the previous form was submitted and then saves the form variables to session variables.
If the back button is pressed and the user goes back to Page1, it will have no effect. If they submit Page1 again the session variables would be changed to whatever was currently in the form fields, which would obviously be what you would want it to do. If somebody went to Page3 and then clicked the back button and went to Page2, the session variables wouldn't be changed because the logic on Page2 checks to see if there was a form submit from Page1.
I use this kind of logic all the time, so I don't see why there should be any back button issues at all. It would be really ugly and unwieldy to try and maintain a flat file to track user variables. The key is: don't set the session variables unless there was a form submit from the page you want to grab the variables from.