Re: VERY IMPORTANT: Sessions in Pages with a Form !

FWIW, I track transactions a little differently, using a MySQL table called Transactions which contains a unique transaction ID and whatever other parameters I may need. The transaction record is created when the form is first loaded and the transaction ID is passed from the form to the processing script. If the processing script is successful, it marks the transaction as complete, otherwise it reports an error and they can use the back button to fix whatever they did wrong, then resubmit it. They can go back and forth as many times as they need. If the transaction is already marked as closed, the script either refuses to process it or just flips into update mode. So far I have not had any problems with this. If they reload the form, the program leaves the old transaction number incomplete and creates a new one. Usually the transaction is completed by adding a row to another table, which has a unique key which can then be stored in the transaction table as a cross reference when it's closed. The transaction table is my history of everything that happened on the site. I check occasionally for incomplete transactions and when there's a lot of them it can indicate problems, bugs, user confusion, etc. Jeff Maxim Maletsky wrote: > > Thank you all for your replies, guys. > > I found it useful by seeing how others were resolving this kind of problems. > > You see, I started using sessions like a mad, all the databases, web pages, > trackers, _admin areas_, local intranet sites in my company are now having > sessions in their config files. which are then going into databases, files, > scripts, and so on... > so we've got lot's of customized info on who did what and how often he does > it. > > This is crucial for us to have it and there's no way to escape from any > config file because of a form or other situation otherwise I would lose the > sequence of a user's/maintainer's "adventure". > > The forms _are_ usually submitted to themselves, most of them are "post". > But there are few things to do with them to save people's content when they > get an error on a form. I can modify the forms of course, but, because I > noticed that it's related to sessions only, I was looking for an answer that > would help me to solve this problem completely. > > Guess it is not really possible right now to do. That's the way sessions are > done, Sasha says. > What about headers, cache control? > > I think it happens this way: > when you get on a page for the first time your browser caches it, and if you > reload the page (remember the page has sessions) the browser still keeps > that cache from the first time - somehow it doesn't update it's previously > cached version of the page. So when you submit something, reload the page, > go to another page then hitting the back button what comes up is the page > cached at the first time you downloaded it. > > I think it's pretty much what happening. I was testing it: > I provocateur a parse error at line 25 on a new page, access it(seeing the > error of course), then remove the error, submit a simple post form, hit back > button: error line 25 is right here. Whatever then I would do with that > page, on hit back -- parse error on line 25. > (and this is not only my PC, I checked others, and asked others on this > planet to tell me what they see) > > If you know/understand what I am talking about, please give me some idea on > fixing, stabilizing this issue. > > Thank you all for your time. > > -----Original Message----- > From: Simon Edwards [mailto:simon@animated.net.au] > Sent: Thursday, September 28, 2000 8:14 AM > To: Maxim Maletsky > Cc: php-general@lists.php.net > Subject: Re: [PHP] VERY IMPORTANT: Sessions in Pages with a Form ! > > Hi, > > > When I use sessions on a page that also has a form in it the back button > > doesn't work. Like when a subscriber gets an error from my script saying > > that he didn't fill the form out completely and he tries to hit back > button > > of his browser the whole form disappears. Every single field becomes > empty. > > Does the browser reload the form when you hit the back button? > > > I know for sure that it is something that has to do with sessions, since > > commenting them, back button will show you "your" form and not an empty > one. > > I guessing that in this scenario you hit the back button and the browser > *did* not reload the form from the server. > > I'm guessing, but it's probably a case of the browser reloading the form > on 'back' when the sessions are used vs it just using a cached version > when no sessions (and cookies) are in use. > > > It is very important for me to resolve this problem, since we saw a BIG > drop > > in subscriptions since I started using sessions in the pages using forms. > > > I know few ways to fix it, like: registering the sessions with the field > > values, outputting the data again when there's an error, recording the > data > > submitted and prompting only for the missing one.. but, it's hard to > explain > > why, I REALLY NEED the back button to work with sessions just like it > would > > be without them, > > Don't use the back button. It fails in may situations. Just put your > form and form responder code in the same page. If the use misses part of > the form, don't use back, just output the form again and put the > submitted form values into the new form HTML. > > -- > Simon Edwards > > Animated Design, Melbourne > http://www.animated.net.au/ Ph: (03) 98850990 > > ------------------------------------------------------------------------ > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, e-mail: php-general-unsubscribe@lists.php.net > For additional commands, e-mail: php-general-help@lists.php.net > To contact the list administrators, e-mail: php-list-admin@lists.php.net