Re: [PHP] Multipage form redux
On 27 Jul 2005, at 21:22, Jack Jackson wrote: Right. Except I would rather have it working in a session because I specifically do not want to have the form sending $_POST data back and forth to the browser six times for several reasons. SO I'd like to Page1 // User enters first batch of data, presses SUBMIT at bottom. Data is cleaned and written to SESSION, user passed to Page2 repeat as necessary to last page. At last page, process and error check newest input, then commit it, plus all previously stored session info to db. As has also been said, Javascript can do this really nicely. The best example I've seen of this is in Mambo's (a popular PHP CMS) admin interface. It uses a tabbed multi-page form with client-side validation. It's really just one big page, so if the user has JS turned off, they will get one big form with no client-side validation, but it will still work. It's a really elegant way of working. It doesn't require any server interaction between pages - nothing is submitted until the form is complete. See here for a howto: http://www.devx.com/webdev/Article/10483/1763/ page/1 Admittedly this approach doesn't easily allow to you abandon and resume later (unless you get clever with JS and cookies). For keeping data in a session, you could combine this approach with Ajax: http://particletree.com/features/smart-validation-with-ajax Marcus -- Marcus Bointon Synchromedia Limited: Putting you in the picture [EMAIL PROTECTED] | http://www.synchromedia.co.uk -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Multipage form redux
Somehow my intent has been turned around here and I apologise. I do not want to use *any* client side validation. I only want to do server side validation and server side storage. My intent was to remove the client from as much as possible of this - if I didn't need their information I wouldn't even allow clients!! :) What I wanted to do was this: p. 1 : I send client page one, they send answers. SUBMIT sends to page 2 script. p 2. Before displaying anything to the client, Page 2 script validates input from page 1. If there are problems, page 2 script redisplays page one questions with highlights around problems. Clicking submit then resubmits page one data to page 2 script. Once page 2 script validates all page 1 answers, page 2 script stores all those answers to a SESSION, then sends PAGE 2 QUESTIONS ONLY (no $_POST information) to client. Client answers page 2 questions and clicking submit submits PAGE 2 QUESTIONS to page 3 script. p 3. Before displaying anything to the client, Page 3 script validates input from page 2 questions. If there are problems, page 3 script redisplays page 2 questions with highlights around problems. Clicking submit resubmits page 2 data to page 3 script. Once page 3 script validates all page 2 answers, the script stores all those answers to a SESSION, then sends PAGE 3 QUESTIONS ONLY (no $_POST information) to client. Client answers page 3 questions and clicking submit submits PAGE 3 QUESTIONS to page 4 script. At this point, if the client goes off for a bite, or two weeks backpacking in the Anapurna region, I'm fine, because the information is stored in the session (I have a very small group taking this questionnaire, all have a vested interested in filling it in, so I am not too worried abou their going aaway from it for more than a couple days max). Once they complete the last set of questions, I say thanks much, get all the information out of their SESSION, insert it into the db, send confirmation emails all around and we're done. Is this possible? How? Thanks! Marcus Bointon wrote: On 27 Jul 2005, at 21:22, Jack Jackson wrote: Right. Except I would rather have it working in a session because I specifically do not want to have the form sending $_POST data back and forth to the browser six times for several reasons. SO I'd like to Page1 // User enters first batch of data, presses SUBMIT at bottom. Data is cleaned and written to SESSION, user passed to Page2 repeat as necessary to last page. At last page, process and error check newest input, then commit it, plus all previously stored session info to db. As has also been said, Javascript can do this really nicely. The best example I've seen of this is in Mambo's (a popular PHP CMS) admin interface. It uses a tabbed multi-page form with client-side validation. It's really just one big page, so if the user has JS turned off, they will get one big form with no client-side validation, but it will still work. It's a really elegant way of working. It doesn't require any server interaction between pages - nothing is submitted until the form is complete. See here for a howto: http://www.devx.com/webdev/Article/10483/1763/ page/1 Admittedly this approach doesn't easily allow to you abandon and resume later (unless you get clever with JS and cookies). For keeping data in a session, you could combine this approach with Ajax: http://particletree.com/features/smart-validation-with-ajax Marcus -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Multipage form redux
The point of sessions is that when you close your browser, you loose it. I'm affraid that if you want sessions that last two weeks, you'll have to make your own session handler :) but yeah, it's possible, and it beats the crap out of the fill form, store in db, fill form, store in db method. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Multipage form redux
Jack Jackson [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Somehow my intent has been turned around here and I apologise. I do not want to use *any* client side validation. I only want to do server side validation and server side storage. My intent was to remove the client from as much as possible of this - if I didn't need their information I wouldn't even allow clients!! :) What I wanted to do was this: p. 1 : I send client page one, they send answers. SUBMIT sends to page 2 script. p 2. Before displaying anything to the client, Page 2 script validates input from page 1. If there are problems, page 2 script redisplays page one questions with highlights around problems. Clicking submit then resubmits page one data to page 2 script. Once page 2 script validates all page 1 answers, page 2 script stores all those answers to a SESSION, then sends PAGE 2 QUESTIONS ONLY (no $_POST information) to client. Client answers page 2 questions and clicking submit submits PAGE 2 QUESTIONS to page 3 script. p 3. Before displaying anything to the client, Page 3 script validates input from page 2 questions. If there are problems, page 3 script redisplays page 2 questions with highlights around problems. Clicking submit resubmits page 2 data to page 3 script. Once page 3 script validates all page 2 answers, the script stores all those answers to a SESSION, then sends PAGE 3 QUESTIONS ONLY (no $_POST information) to client. Client answers page 3 questions and clicking submit submits PAGE 3 QUESTIONS to page 4 script. At this point, if the client goes off for a bite, or two weeks backpacking in the Anapurna region, I'm fine, because the information is stored in the session (I have a very small group taking this questionnaire, all have a vested interested in filling it in, so I am not too worried abou their going aaway from it for more than a couple days max). Once they complete the last set of questions, I say thanks much, get all the information out of their SESSION, insert it into the db, send confirmation emails all around and we're done. Sessions are used to identify users on a single visit to a website. They are not intended to track users who turn off their machines, then turn them on again and visit the website again. There are various ways of doing this, and for all I know it may be possible with sessions, but I don't recommend you try. Do as suggested previously by various posters, it is the simplest and most robust solution to your problem: 1. have the user register their details first up. Store this in a db, and use it to identify the user on any subsequent visit. 2. when each page is submitted, write the information into the db. This way it will definitely be associated with the right user 3. Whenever a user revisits the questionnaire, make them log in, then take them to wherever they were up to - you will be able to work this out from the amount of data you have recorded against them. e.g. database table userid question question question question question question Is this possible? How? Thanks! Marcus Bointon wrote: On 27 Jul 2005, at 21:22, Jack Jackson wrote: Right. Except I would rather have it working in a session because I specifically do not want to have the form sending $_POST data back and forth to the browser six times for several reasons. SO I'd like to Page1 // User enters first batch of data, presses SUBMIT at bottom. Data is cleaned and written to SESSION, user passed to Page2 repeat as necessary to last page. At last page, process and error check newest input, then commit it, plus all previously stored session info to db. As has also been said, Javascript can do this really nicely. The best example I've seen of this is in Mambo's (a popular PHP CMS) admin interface. It uses a tabbed multi-page form with client-side validation. It's really just one big page, so if the user has JS turned off, they will get one big form with no client-side validation, but it will still work. It's a really elegant way of working. It doesn't require any server interaction between pages - nothing is submitted until the form is complete. See here for a howto: http://www.devx.com/webdev/Article/10483/1763/ page/1 Admittedly this approach doesn't easily allow to you abandon and resume later (unless you get clever with JS and cookies). For keeping data in a session, you could combine this approach with Ajax: http://particletree.com/features/smart-validation-with-ajax Marcus -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Multipage form redux
Jack Jackson [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Somehow my intent has been turned around here and I apologise. I do not want to use *any* client side validation. I only want to do server side validation and server side storage. My intent was to remove the client from as much as possible of this - if I didn't need their information I wouldn't even allow clients!! :) What I wanted to do was this: p. 1 : I send client page one, they send answers. SUBMIT sends to page 2 script. p 2. Before displaying anything to the client, Page 2 script validates input from page 1. If there are problems, page 2 script redisplays page one questions with highlights around problems. Clicking submit then resubmits page one data to page 2 script. Once page 2 script validates all page 1 answers, page 2 script stores all those answers to a SESSION, then sends PAGE 2 QUESTIONS ONLY (no $_POST information) to client. Client answers page 2 questions and clicking submit submits PAGE 2 QUESTIONS to page 3 script. p 3. Before displaying anything to the client, Page 3 script validates input from page 2 questions. If there are problems, page 3 script redisplays page 2 questions with highlights around problems. Clicking submit resubmits page 2 data to page 3 script. Once page 3 script validates all page 2 answers, the script stores all those answers to a SESSION, then sends PAGE 3 QUESTIONS ONLY (no $_POST information) to client. Client answers page 3 questions and clicking submit submits PAGE 3 QUESTIONS to page 4 script. At this point, if the client goes off for a bite, or two weeks backpacking in the Anapurna region, I'm fine, because the information is stored in the session (I have a very small group taking this questionnaire, all have a vested interested in filling it in, so I am not too worried abou their going aaway from it for more than a couple days max). Once they complete the last set of questions, I say thanks much, get all the information out of their SESSION, insert it into the db, send confirmation emails all around and we're done. Sessions are used to identify users on a single visit to a website. They are not intended to track users who turn off their machines, then turn them on again and visit the website again. There are various ways of doing this, and for all I know it may be possible with sessions, but I don't recommend you try. Do as suggested previously by various posters, it is the simplest and most robust solution to your problem: 1. have the user register their details first up. Store this in a db, and use it to identify the user on any subsequent visit. 2. when each page is submitted, write the information into the db. This way it will definitely be associated with the right user 3. Whenever a user revisits the questionnaire, make them log in, then take them to wherever they were up to - you will be able to work this out from the amount of data you have recorded against them. e.g. database table tbluser userid password tblanswers userid question1 question2 question3 question4 question5 question6 etc Scenario 1 A user logs into the questionnaire. No row is present in tbluser for this user, so create one, and send the user to the first page of the questionnaire Scenario 2 A user logs into the questionnaire. There is a row in tbluser, and tblanswers also has a row, with data in columns userid, question1 and question2. Direct this user to the third page of the questionnaire I hope this is clearer Mark Is this possible? How? Thanks! Marcus Bointon wrote: On 27 Jul 2005, at 21:22, Jack Jackson wrote: Right. Except I would rather have it working in a session because I specifically do not want to have the form sending $_POST data back and forth to the browser six times for several reasons. SO I'd like to Page1 // User enters first batch of data, presses SUBMIT at bottom. Data is cleaned and written to SESSION, user passed to Page2 repeat as necessary to last page. At last page, process and error check newest input, then commit it, plus all previously stored session info to db. As has also been said, Javascript can do this really nicely. The best example I've seen of this is in Mambo's (a popular PHP CMS) admin interface. It uses a tabbed multi-page form with client-side validation. It's really just one big page, so if the user has JS turned off, they will get one big form with no client-side validation, but it will still work. It's a really elegant way of working. It doesn't require any server interaction between pages - nothing is submitted until the form is complete. See here for a howto: http://www.devx.com/webdev/Article/10483/1763/ page/1 Admittedly this approach doesn't easily allow to you abandon and resume later (unless you get clever with JS and cookies). For keeping data in a session, you could combine this approach with Ajax:
Re: [PHP] Multipage form redux
The light dawns. Thank you everyone for this explanation, and the help JJ Mark Rees wrote: Jack Jackson [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Somehow my intent has been turned around here and I apologise. I do not want to use *any* client side validation. I only want to do server side validation and server side storage. My intent was to remove the client from as much as possible of this - if I didn't need their information I wouldn't even allow clients!! :) What I wanted to do was this: p. 1 : I send client page one, they send answers. SUBMIT sends to page 2 script. p 2. Before displaying anything to the client, Page 2 script validates input from page 1. If there are problems, page 2 script redisplays page one questions with highlights around problems. Clicking submit then resubmits page one data to page 2 script. Once page 2 script validates all page 1 answers, page 2 script stores all those answers to a SESSION, then sends PAGE 2 QUESTIONS ONLY (no $_POST information) to client. Client answers page 2 questions and clicking submit submits PAGE 2 QUESTIONS to page 3 script. p 3. Before displaying anything to the client, Page 3 script validates input from page 2 questions. If there are problems, page 3 script redisplays page 2 questions with highlights around problems. Clicking submit resubmits page 2 data to page 3 script. Once page 3 script validates all page 2 answers, the script stores all those answers to a SESSION, then sends PAGE 3 QUESTIONS ONLY (no $_POST information) to client. Client answers page 3 questions and clicking submit submits PAGE 3 QUESTIONS to page 4 script. At this point, if the client goes off for a bite, or two weeks backpacking in the Anapurna region, I'm fine, because the information is stored in the session (I have a very small group taking this questionnaire, all have a vested interested in filling it in, so I am not too worried abou their going aaway from it for more than a couple days max). Once they complete the last set of questions, I say thanks much, get all the information out of their SESSION, insert it into the db, send confirmation emails all around and we're done. Sessions are used to identify users on a single visit to a website. They are not intended to track users who turn off their machines, then turn them on again and visit the website again. There are various ways of doing this, and for all I know it may be possible with sessions, but I don't recommend you try. Do as suggested previously by various posters, it is the simplest and most robust solution to your problem: 1. have the user register their details first up. Store this in a db, and use it to identify the user on any subsequent visit. 2. when each page is submitted, write the information into the db. This way it will definitely be associated with the right user 3. Whenever a user revisits the questionnaire, make them log in, then take them to wherever they were up to - you will be able to work this out from the amount of data you have recorded against them. e.g. database table userid question question question question question question Is this possible? How? Thanks! Marcus Bointon wrote: On 27 Jul 2005, at 21:22, Jack Jackson wrote: Right. Except I would rather have it working in a session because I specifically do not want to have the form sending $_POST data back and forth to the browser six times for several reasons. SO I'd like to Page1 // User enters first batch of data, presses SUBMIT at bottom. Data is cleaned and written to SESSION, user passed to Page2 repeat as necessary to last page. At last page, process and error check newest input, then commit it, plus all previously stored session info to db. As has also been said, Javascript can do this really nicely. The best example I've seen of this is in Mambo's (a popular PHP CMS) admin interface. It uses a tabbed multi-page form with client-side validation. It's really just one big page, so if the user has JS turned off, they will get one big form with no client-side validation, but it will still work. It's a really elegant way of working. It doesn't require any server interaction between pages - nothing is submitted until the form is complete. See here for a howto: http://www.devx.com/webdev/Article/10483/1763/ page/1 Admittedly this approach doesn't easily allow to you abandon and resume later (unless you get clever with JS and cookies). For keeping data in a session, you could combine this approach with Ajax: http://particletree.com/features/smart-validation-with-ajax Marcus -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Multipage form redux
Jack Jackson [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Somehow my intent has been turned around here and I apologise. I do not want to use *any* client side validation. I only want to do server side validation and server side storage. My intent was to remove the client from as much as possible of this - if I didn't need their information I wouldn't even allow clients!! :) What I wanted to do was this: p. 1 : I send client page one, they send answers. SUBMIT sends to page 2 script. p 2. Before displaying anything to the client, Page 2 script validates input from page 1. If there are problems, page 2 script redisplays page one questions with highlights around problems. Clicking submit then resubmits page one data to page 2 script. Once page 2 script validates all page 1 answers, page 2 script stores all those answers to a SESSION, then sends PAGE 2 QUESTIONS ONLY (no $_POST information) to client. Client answers page 2 questions and clicking submit submits PAGE 2 QUESTIONS to page 3 script. p 3. Before displaying anything to the client, Page 3 script validates input from page 2 questions. If there are problems, page 3 script redisplays page 2 questions with highlights around problems. Clicking submit resubmits page 2 data to page 3 script. Once page 3 script validates all page 2 answers, the script stores all those answers to a SESSION, then sends PAGE 3 QUESTIONS ONLY (no $_POST information) to client. Client answers page 3 questions and clicking submit submits PAGE 3 QUESTIONS to page 4 script. At this point, if the client goes off for a bite, or two weeks backpacking in the Anapurna region, I'm fine, because the information is stored in the session (I have a very small group taking this questionnaire, all have a vested interested in filling it in, so I am not too worried abou their going aaway from it for more than a couple days max). Once they complete the last set of questions, I say thanks much, get all the information out of their SESSION, insert it into the db, send confirmation emails all around and we're done. Sessions are used to identify users on a single visit to a website. They are not intended to track users who turn off their machines, then turn them on again and visit the website again. There are various ways of doing this, and for all I know it may be possible with sessions, but I don't recommend you try. Do as suggested previously by various posters, it is the simplest and most robust solution to your problem: 1. have the user register their details first up. Store this in a db, and use it to identify the user on any subsequent visit. 2. when each page is submitted, write the information into the db. This way it will definitely be associated with the right user 3. Whenever a user revisits the questionnaire, make them log in, then take them to wherever they were up to - you will be able to work this out from the amount of data you have recorded against them. e.g. database table tbluser userid password tblanswers userid question1 question2 question3 question4 question5 question6 etc Scenario 1 A user logs into the questionnaire. No row is present in tbluser for this user, so create one, and send the user to the first page of the questionnaire Scenario 2 A user logs into the questionnaire. There is a row in tbluser, and tblanswers also has a row, with data in columns userid, question1 and question2. Direct this user to the third page of the questionnaire I hope this is clearer Mark Is this possible? How? Thanks! Marcus Bointon wrote: On 27 Jul 2005, at 21:22, Jack Jackson wrote: Right. Except I would rather have it working in a session because I specifically do not want to have the form sending $_POST data back and forth to the browser six times for several reasons. SO I'd like to Page1 // User enters first batch of data, presses SUBMIT at bottom. Data is cleaned and written to SESSION, user passed to Page2 repeat as necessary to last page. At last page, process and error check newest input, then commit it, plus all previously stored session info to db. As has also been said, Javascript can do this really nicely. The best example I've seen of this is in Mambo's (a popular PHP CMS) admin interface. It uses a tabbed multi-page form with client-side validation. It's really just one big page, so if the user has JS turned off, they will get one big form with no client-side validation, but it will still work. It's a really elegant way of working. It doesn't require any server interaction between pages - nothing is submitted until the form is complete. See here for a howto: http://www.devx.com/webdev/Article/10483/1763/ page/1 Admittedly this approach doesn't easily allow to you abandon and resume later (unless you get clever with JS and cookies). For keeping data in a session, you could combine this approach with Ajax:
RE: [PHP] Multipage form redux
Somehow my intent has been turned around here and I apologise.
I do not want to use *any* client side validation. I only want to do
server side validation and server side storage.
My intent was to remove the client from as much as possible
of this - if
I didn't need their information I wouldn't even allow clients!! :)
What I wanted to do was this:
p. 1 : I send client page one, they send answers. SUBMIT
sends to page 2
script.
p 2. Before displaying anything to the client, Page 2 script
validates
input from page 1. If there are problems, page 2 script
redisplays page
one questions with highlights around problems. Clicking submit then
resubmits page one data to page 2 script.
Once page 2 script validates all page 1 answers, page 2 script stores
all those answers to a SESSION, then sends PAGE 2 QUESTIONS ONLY (no
$_POST information) to client. Client answers page 2 questions and
clicking submit submits PAGE 2 QUESTIONS to page 3 script.
p 3. Before displaying anything to the client, Page 3 script
validates
input from page 2 questions. If there are problems, page 3 script
redisplays page 2 questions with highlights around problems. Clicking
submit resubmits page 2 data to page 3 script.
Once page 3 script validates all page 2 answers, the script
stores all
those answers to a SESSION, then sends PAGE 3 QUESTIONS ONLY
(no $_POST
information) to client. Client answers page 3 questions and clicking
submit submits PAGE 3 QUESTIONS to page 4 script.
At this point, if the client goes off for a bite, or two weeks
backpacking in the Anapurna region, I'm fine, because the
information is
stored in the session (I have a very small group taking this
questionnaire, all have a vested interested in filling it in, so I am
not too worried abou their going aaway from it for more than a couple
days max).
Once they complete the last set of questions, I say thanks
much, get all
the information out of their SESSION, insert it into the db, send
confirmation emails all around and we're done.
Is this possible? How?
Thanks!
This is exactly the scenario I suggested. The only place I believe your
logic fails is that the session will time out after a period of time and all
data will be lost. If you suspect that a user may need to resume an
interrupted session, you need to store the data somewhere (DB, cookies, etc)
Consider this over-simplified and (probably syntactically incorrect)
example:
? // Page 1
session_start();
?
html
head
titlePage 1/title
/head
body
form method=POST action=page2.php
pNAME: input type=text name=NAME value=? echo
$_SESSION['Name']?/p
pinput type=submit value=Submit name=B1/p
/form
/body
/html
? // Page 2
$_SESSION['Name'] = $_POST['NAME']; // commit to session variables
// Validate data here
if (data problems){die('meta http-equiv=refresh
content=0;url=page1.php');}
?
html
head
titlePage 1/title
/head
body
form method=POST action=page3.php
pADDRESS: input type=text name=ADDRESS value=? echo
$_SESSION['Address']?/p
pinput type=submit value=Submit name=B1/p
/form
/body
/html
? // Page 3
$_SESSION['Address'] = $_POST['ADDRESS'];// commit to session variables
// Validate data here
if (data problems){die('meta http-equiv=refresh
content=0;url=page1.php');}
?
html
head
titlePage 1/title
/head
body
form method=POST action=page4.php
pPHONE: input type=text name=PHONE value=? echo
$_SESSION['Phone']?/p
pinput type=submit value=Submit name=B1/p
/form
/body
/html
This is incredibly over-simplified, but you get the idea. If you want to
redisplay the form and highlight data errors, you may want to POST to
PHP_SELF, validate there, redisplay the form if necessary, and meta-refresh
to the next page if all is OK.
JM
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Multipage form redux
On 28 July 2005 13:39, Jack Jackson wrote: What I wanted to do was this: p. 1 : I send client page one, they send answers. SUBMIT sends to page 2 script. p 2. Before displaying anything to the client, Page 2 script validates input from page 1. If there are problems, page 2 script redisplays page one questions with highlights around problems. Clicking submit then resubmits page one data to page 2 script. Once page 2 script validates all page 1 answers, page 2 script stores all those answers to a SESSION, then sends PAGE 2 QUESTIONS ONLY (no $_POST information) to client. Client answers page 2 questions and clicking submit submits PAGE 2 QUESTIONS to page 3 script. [] Is this possible? How? With the caveat that I agree with what everyone has said about the duration of sessions, my answers to your 2 questions are: Yes. And exactly as you have described it. So what part of the implementation in PHP do you *really* not understand? Cheers! Mike - Mike Ford, Electronic Information Services Adviser, Learning Support Services, Learning Information Services, JG125, James Graham Building, Leeds Metropolitan University, Headingley Campus, LEEDS, LS6 3QS, United Kingdom Email: [EMAIL PROTECTED] Tel: +44 113 283 2600 extn 4730 Fax: +44 113 283 3211 To view the terms under which this email is distributed, please go to http://disclaimer.leedsmet.ac.uk/email.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Multipage form redux
André Medeiros [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] The point of sessions is that when you close your browser, you loose it. I'm affraid that if you want sessions that last two weeks, you'll have to make your own session handler :) but yeah, it's possible, and it beats the crap out of the fill form, store in db, fill form, store in db method. Unless your user wishes to complete the form from a different machine, of course. I really don't understand the dogmatic antipathy to storing information in the database. Sometimes it is a better solution - horses for courses. Rolling your own session management tool, whilst undoubtedly fun and satisfying, is hardly an appropriate solution to this type of enquiry, which is apparently from someone taking their first steps in web development. I should probably explain that I come from an ASP background and so have an inherent mistrust of sessions, although I am coming to understand that PHP sessions are much more reliable. Sorry about the three posts before, my mistake. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Multipage form redux
André Medeiros [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] The point of sessions is that when you close your browser, you loose it. I'm affraid that if you want sessions that last two weeks, you'll have to make your own session handler :) but yeah, it's possible, and it beats the crap out of the fill form, store in db, fill form, store in db method. Unless your user wishes to complete the form from a different machine, of course. I really don't understand the dogmatic antipathy to storing information in the database. Sometimes it is a better solution - horses for courses. Rolling your own session management tool, whilst undoubtedly fun and satisfying, is hardly an appropriate solution to this type of enquiry, which is apparently from someone taking their first steps in web development. I should probably explain that I come from an ASP background and so have an inherent mistrust of sessions, although I am coming to understand that PHP sessions are much more reliable. I agree. In this case, it is my opinion that storing data in the DB after each successful page is the best solution. I would be interested to hear why it is a bad idea. JM -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Multipage form redux
Mark Rees wrote: André Medeiros [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] The point of sessions is that when you close your browser, you loose it. I'm affraid that if you want sessions that last two weeks, you'll have to make your own session handler :) but yeah, it's possible, and it beats the crap out of the fill form, store in db, fill form, store in db method. Unless your user wishes to complete the form from a different machine, of course. I really don't understand the dogmatic antipathy to storing information in the database. Sometimes it is a better solution - horses for courses. Rolling your own session management tool, whilst undoubtedly fun and satisfying, is hardly an appropriate solution to this type of enquiry, which is apparently from someone taking their first steps in web development. I should probably explain that I come from an ASP background and so have an inherent mistrust of sessions, although I am coming to understand that PHP sessions are much more reliable. Sorry about the three posts before, my mistake. No, I think I wasn't clear because of a fundamental misunderstanding on my part of the problem of SESSIONS not lasting between ... uh... sessions. In fact I think my very first post on the subject did in fact say I wanted to store the answers on the db throughout the process, but I got so excited at the prospect of having sessions store things that I got distracted. Anyway, thanks again to all who replied and for all the help I generally receive here on the list!! JJ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Multipage form redux
On 28 Jul 2005, at 14:13, Mark Rees wrote: Rolling your own session management tool, whilst undoubtedly fun and satisfying, is hardly an appropriate solution to this type of enquiry, which is apparently from someone taking their first steps in web development. Unsurprisingly, this is a situation that has been encountered many times before, and there are off-the-shelf solutions. ADOdb has a really nice session manager: http://phplens.com/lens/adodb/docs- session.htm Database-backed sessions are particularly useful if you have multiple redundant web servers as successive hits within a session may go to different servers, so file- or memory-based sessions are not much use. Despite this, I also suspect that sessions may not be the way to go. User authentication and management is not a synonym for sessions. Marcus -- Marcus Bointon Synchromedia Limited: Putting you in the picture [EMAIL PROTECTED] | http://www.synchromedia.co.uk -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Multipage form redux
On Wed, 2005-07-27 at 07:51 -0400, Jack Jackson wrote: Hi, I have searched the archives and seen links to tutorials at phpclasses (which seem to be down) and not found an answer to my question: I have a long form I want to break into seven pages. Rather than pass values from page to page as hidden, I'd rather write the results to the db after each page then move on. Anyone know of any tutorials on this? Thanks in advance, JJ That's not a very good idea. Imagine the user gets to the fourth form and gets a cup of coffee, or goes out to lunch. By the time he gets to the computer he might have lost the session, thus having data on your DB that is wasting space. And what if the user closes the browser window? :) Bad bad idea. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Multipage form redux
André Medeiros [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] On Wed, 2005-07-27 at 07:51 -0400, Jack Jackson wrote: Hi, I have searched the archives and seen links to tutorials at phpclasses (which seem to be down) and not found an answer to my question: I have a long form I want to break into seven pages. Rather than pass values from page to page as hidden, I'd rather write the results to the db after each page then move on. Anyone know of any tutorials on this? Thanks in advance, JJ That's not a very good idea. Imagine the user gets to the fourth form and gets a cup of coffee, or goes out to lunch. By the time he gets to the computer he might have lost the session, thus having data on your DB that is wasting space. And what if the user closes the browser window? :) Bad bad idea. What if the form takes ages to fill out, and the user has to go away and find out other information, then wants to come back to the form and see it pre-filled? For an insurance quote, say? It could be a good idea under those circumstances. You can always delete all incomplete data with a cron job every week or so if needs be. Do you know how to write data to a db? The mechanics of what you want to do are not especially complex. page 1 form vars page 2 request form vars, write to db, display form etc -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Multipage form redux
Thanks everyone. I take the point of Andre, but believe that the depth and sensitivity of the data require it be stored server side. I think that Richard and Mark have put their fingers on it - it's gotta be cookie based. Someone on the IRC suggested sessions and I think that it the way it goes. As for the idea that new users would be sent packing by such a ridiculously long form, right on! This is a form to be filled in by a client of the company after they've hired to company to provide an assessment of ther practices, so they'd expect a long form. But point taken Thanks everyone for replying so quickly! I'll come back when I botch the sessions and need help fixing!! JJ Richard Davey wrote: Hello André, Wednesday, July 27, 2005, 2:22:30 PM, you wrote: AM That's not a very good idea. Imagine the user gets to the fourth AM form and gets a cup of coffee, or goes out to lunch. By the time AM he gets to the computer he might have lost the session, thus AM having data on your DB that is wasting space. AM And what if the user closes the browser window? :) All of those things are unavoidable no matter what technique you use :) I've seen multi-page forms with a Finish this later option that issues a cookie to your browser, allowing you to visit the site at any (realistic) point in the future and carry on. In which cases the part-filled contents must already be in a database somewhere. This isn't a bad thing imho, it's a nice touch. Of course it's prone to the usual browser doesn't accept cookies / browser deletes cookies syndrome though. If you don't want to pass the form values across in a hidden manner (and I don't blame you) then it's either dump it all in a session and hope it doesn't time-out, or dump it into a database, issue the visitor some link to that entry (cookie, session var) and again hope they don't time out. The only real difference being the DB option will need purging to get rid of incomplete forms X days old. But that in itself could prove a useful statistic for reports. Unless you're dealing with thousands of sign-ups an hour, I don't see any issue with this option. Another technique might be the following - rethink how your forms work. Exactly what is it you're collecting data about? If it's part of a long sign-up process then you could consider changing the process around a bit - so that the VERY first thing the user does is create a temporary account on your site (call them incomplete users). So you grab some method of login + authentication details from them. Then the form pages following this can all be saved to a DB and linked to that user. So, as long as they complete this first step, they can always come back and finish the job off - whenever they want, avoiding cookie and session time-out issues. This won't work for all forms of course, it depends what the nature of the process is, but it's certainly an option. Best regards, Richard Davey -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Multipage form redux
hi, my first attempt at a sessions-based form is starting at
http://pastebin.com/322696
and I have a question. What I want to do is, after the user answers the
questions in section one and they are error checked, I want to write the
answers to $_SESSION() and then continue down the script to the next
page of questions. I do *not* want to re-send the answers from page one
as $_POST vars back to the user and have the user submit the answers to
page 2 plus the $_POST answers from page 1.
What I am doing now is clearly wrong, basically :
if (empty($error)) {
include_once($page2);
}
because that's keeping it all in one script. But how should I be getting
to the next page, sending headers to a new script, and at the end of the
chain the script which pulls it all together?
Thanks in advance,
JJ
Jack Jackson wrote:
Thanks everyone. I take the point of Andre, but believe that the depth
and sensitivity of the data require it be stored server side. I think
that Richard and Mark have put their fingers on it - it's gotta be
cookie based. Someone on the IRC suggested sessions and I think that it
the way it goes. As for the idea that new users would be sent packing by
such a ridiculously long form, right on! This is a form to be filled in
by a client of the company after they've hired to company to provide an
assessment of ther practices, so they'd expect a long form. But point taken
Thanks everyone for replying so quickly!
I'll come back when I botch the sessions and need help fixing!!
JJ
Richard Davey wrote:
Hello André,
Wednesday, July 27, 2005, 2:22:30 PM, you wrote:
AM That's not a very good idea. Imagine the user gets to the fourth
AM form and gets a cup of coffee, or goes out to lunch. By the time
AM he gets to the computer he might have lost the session, thus
AM having data on your DB that is wasting space.
AM And what if the user closes the browser window? :)
All of those things are unavoidable no matter what technique you use
:)
I've seen multi-page forms with a Finish this later option that
issues a cookie to your browser, allowing you to visit the site at any
(realistic) point in the future and carry on. In which cases the
part-filled contents must already be in a database somewhere. This
isn't a bad thing imho, it's a nice touch.
Of course it's prone to the usual browser doesn't accept cookies /
browser deletes cookies syndrome though.
If you don't want to pass the form values across in a hidden manner
(and I don't blame you) then it's either dump it all in a session and
hope it doesn't time-out, or dump it into a database, issue the
visitor some link to that entry (cookie, session var) and again hope
they don't time out.
The only real difference being the DB option will need purging to get
rid of incomplete forms X days old. But that in itself could prove a
useful statistic for reports. Unless you're dealing with thousands of
sign-ups an hour, I don't see any issue with this option.
Another technique might be the following - rethink how your forms
work. Exactly what is it you're collecting data about? If it's part of
a long sign-up process then you could consider changing the process
around a bit - so that the VERY first thing the user does is create a
temporary account on your site (call them incomplete users). So you
grab some method of login + authentication details from them. Then the
form pages following this can all be saved to a DB and linked to that
user.
So, as long as they complete this first step, they can always come
back and finish the job off - whenever they want, avoiding cookie and
session time-out issues.
This won't work for all forms of course, it depends what the nature of
the process is, but it's certainly an option.
Best regards,
Richard Davey
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Multipage form redux
-Original Message-
From: Jack Jackson [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 27, 2005 3:47 PM
To: php [php] PHP General List
Subject: Re: [PHP] Multipage form redux
hi, my first attempt at a sessions-based form is starting at
http://pastebin.com/322696
and I have a question. What I want to do is, after the user
answers the
questions in section one and they are error checked, I want
to write the
answers to $_SESSION() and then continue down the script to the next
page of questions. I do *not* want to re-send the answers
from page one
as $_POST vars back to the user and have the user submit the
answers to
page 2 plus the $_POST answers from page 1.
What I am doing now is clearly wrong, basically :
if (empty($error)) {
include_once($page2);
}
because that's keeping it all in one script. But how should I
be getting
to the next page, sending headers to a new script, and at the
end of the
chain the script which pulls it all together?
Thanks in advance,
JJ
This seems so simple to me. As I understand it, you want to split a data
entry session into several pages. You don't want to collect the data and
submit it all at the end, but instead commit it to session variables along
the way. Am I missing something?
Here's how I would do it in a nutshell:
Page1 // User enters first batch of data, presses SUBMIT at bottom. Data is
POSTed to Page2
Page2 // Commit data from page 1 to session variables, then displays form
for next batch of data. User presses SUBMIT, posts data to Page 3.
Page3 // Commit data from page 2 to session variables, then displays form
for next batch of data. User presses SUBMIT, posts data to Page 4.
... etc etc etc (Each page begins by assigning data from the previous page
to session variables)
Page515 // Displays all session variables set in previous pages, asks user
to confirm. User confirms by pressing SUBMIT, confirmation POSTed to page
516, who writes it all to the database, and sends confirmation email.
Personally, I would take the advice of a previous poster and start off
assigning a username and password to the user. Then store each page in the
database as the user progresses. That way, if he is interrupted in the
middle of the process, he won't lose all his data and have to start over.
He can just enter his username and pick up where he left off. You will just
have to write a script that purges old incomplete records. (A great job for
cron!)
JM
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Multipage form redux
Jim Moseby wrote:
-Original Message-
From: Jack Jackson [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 27, 2005 3:47 PM
To: php [php] PHP General List
Subject: Re: [PHP] Multipage form redux
hi, my first attempt at a sessions-based form is starting at
http://pastebin.com/322696
and I have a question. What I want to do is, after the user
answers the
questions in section one and they are error checked, I want
to write the
answers to $_SESSION() and then continue down the script to the next
page of questions. I do *not* want to re-send the answers
from page one
as $_POST vars back to the user and have the user submit the
answers to
page 2 plus the $_POST answers from page 1.
What I am doing now is clearly wrong, basically :
if (empty($error)) {
include_once($page2);
}
because that's keeping it all in one script. But how should I
be getting
to the next page, sending headers to a new script, and at the
end of the
chain the script which pulls it all together?
Thanks in advance,
JJ
This seems so simple to me. As I understand it, you want to split a data
entry session into several pages. You don't want to collect the data and
submit it all at the end, but instead commit it to session variables along
the way. Am I missing something?
Here's how I would do it in a nutshell:
Page1 // User enters first batch of data, presses SUBMIT at bottom. Data is
POSTed to Page2
Page2 // Commit data from page 1 to session variables, then displays form
for next batch of data. User presses SUBMIT, posts data to Page 3.
Page3 // Commit data from page 2 to session variables, then displays form
for next batch of data. User presses SUBMIT, posts data to Page 4.
... etc etc etc (Each page begins by assigning data from the previous page
to session variables)
Page515 // Displays all session variables set in previous pages, asks user
to confirm. User confirms by pressing SUBMIT, confirmation POSTed to page
516, who writes it all to the database, and sends confirmation email.
Personally, I would take the advice of a previous poster and start off
assigning a username and password to the user. Then store each page in the
database as the user progresses. That way, if he is interrupted in the
middle of the process, he won't lose all his data and have to start over.
He can just enter his username and pick up where he left off. You will just
have to write a script that purges old incomplete records. (A great job for
cron!)
JM
Right. Except I would rather have it working in a session because I
specifically do not want to have the form sending $_POST data back and
forth to the browser six times for several reasons. SO I'd like to
Page1 // User enters first batch of data, presses SUBMIT at bottom.
Data is cleaned and written to SESSION, user passed to Page2
repeat as necessary to last page. At last page, process and error check
newest input, then commit it, plus all previously stored session info to
db.
Does this make sense?
Thanks in advance
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Multipage form redux
Jim Moseby wrote:
-Original Message-
From: Jack Jackson [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 27, 2005 3:47 PM
To: php [php] PHP General List
Subject: Re: [PHP] Multipage form redux
hi, my first attempt at a sessions-based form is starting at
http://pastebin.com/322696
and I have a question. What I want to do is, after the user
answers the
questions in section one and they are error checked, I want
to write the
answers to $_SESSION() and then continue down the script to
the next
page of questions. I do *not* want to re-send the answers
from page one
as $_POST vars back to the user and have the user submit the
answers to
page 2 plus the $_POST answers from page 1.
What I am doing now is clearly wrong, basically :
if (empty($error)) {
include_once($page2);
}
because that's keeping it all in one script. But how should I
be getting
to the next page, sending headers to a new script, and at the
end of the
chain the script which pulls it all together?
Thanks in advance,
JJ
This seems so simple to me. As I understand it, you want
to split a data
entry session into several pages. You don't want to
collect the data and
submit it all at the end, but instead commit it to session
variables along
the way. Am I missing something?
Here's how I would do it in a nutshell:
Page1 // User enters first batch of data, presses SUBMIT at
bottom. Data is
POSTed to Page2
Page2 // Commit data from page 1 to session variables, then
displays form
for next batch of data. User presses SUBMIT, posts data to Page 3.
Page3 // Commit data from page 2 to session variables, then
displays form
for next batch of data. User presses SUBMIT, posts data to Page 4.
... etc etc etc (Each page begins by assigning data from
the previous page
to session variables)
Page515 // Displays all session variables set in previous
pages, asks user
to confirm. User confirms by pressing SUBMIT, confirmation
POSTed to page
516, who writes it all to the database, and sends
confirmation email.
Personally, I would take the advice of a previous poster
and start off
assigning a username and password to the user. Then store
each page in the
database as the user progresses. That way, if he is
interrupted in the
middle of the process, he won't lose all his data and have
to start over.
He can just enter his username and pick up where he left
off. You will just
have to write a script that purges old incomplete records.
(A great job for
cron!)
JM
Right. Except I would rather have it working in a session because I
specifically do not want to have the form sending $_POST data
back and
forth to the browser six times for several reasons. SO I'd like to
Page1 // User enters first batch of data, presses SUBMIT at bottom.
Data is cleaned and written to SESSION, user passed to Page2
repeat as necessary to last page. At last page, process and
error check
newest input, then commit it, plus all previously stored
session info to
db.
Does this make sense?
Thanks in advance
Makes sense. I do not believe you can do this without client-side scripting
(Javascript, AJAX, etc) You cannot (otherwise)process data that has not
been sent back to be processed.
JM
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Multipage form
On Wednesday, March 20, 2002, at 11:57 AM, David Johansen wrote: I was just wondering what was the best way to handle a multipage form. Would the best way be to keep passing the variables through the forms as hidden values or should I use sessions and store all the values as session variables? What's the best way to handle all of this? Also the different forms will all be in the same php file that loops to itself if that makes a difference. Thanks, These can be a pain in the ASS. But as for the answer to your question, it's really more a matter of personal preference and the particular application you have. For instance, if I were writing a shopping cart or some extremely complicated sequence of forms that fork off into a tree-like structure, I'd probably just give up on hidden form fields and use session variables. But because session variables can be tricky to unset (you have to make sure the user explicitly executes a script to unset them), I try to avoid it when I can. I have a linear multi-part form (not one that branches into different directions) where I take user input and throw it all into hidden form fields -- very tedious, yes, but I have finer control over what values get passed around as the user moves on. Side note: the trickiest thing can be getting multiple-listbox values to be passed on, since it'll be hard to put multiple values into a single form field. The way to do it is a miniature loop for each case where you need to do this, that places each value into an element of an array -- then implode the array into a string and put the string into the hidden form field. Explode the string back into an array on the next part of the form. For a branching, tree-like system I'd probably use sessions unless for some reason you can't -- just make sure the user has a way of knowing what's in their cart (or equivalent for your site) somewhere, so that if they closed the window in the middle of filling out the form, possibly expecting it to reset all of their work, then they won't be surprised when they try to fill out the same form later and see all of their old values from their session. Good luck Erik Erik Price Web Developer Temp Media Lab, H.H. Brown [EMAIL PROTECTED] -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Multipage form
On Wed, 20 Mar 2002, David Johansen wrote:
I was just wondering what was the best way to handle a multipage form. Would
the best way be to keep passing the variables through the forms as hidden
values or should I use sessions and store all the values as session
variables? What's the best way to handle all of this? Also the different
forms will all be in the same php file that loops to itself if that makes a
difference.
Erik gives you some good advice.
The best I can add is to minimize your expectations about rational
behavior on the part of your users. People will use the back button to go
back and change their answers, etc., no matter how much you tell them not
to.
For really complicated forms I usually build (from leftover parts in our
virtual basement) a system something like this:
1) An array ('form_fields') describing all the form items on all the
pages. This describes what type of form element, how it's labeled, which
other elements it depends on, whether it's mandatory, etc.
2) Another array ('field_pages') that says which of these should ideally
appear on which apges, and in which sequence.
3) A set of functions that can draw any form element based on the
definitions in array form_fields above.
4) Iterate through array field_pages above, drawing all the items on the
page we currently think we're on (this is the one thing we store in a
hidden variable; everything else stays in a session array).
5) When the form is submitted, check through the items that array
field_pages says should be on the page identified by the hidden variable.
If any marked as mandatory are not completed, generate an error label
indexed on its form_fields key. Do the same for any other errors.
6) If we have anything in our error label array, re-draw those fields,
labeled with the appropriate error messages, and return to step 5.
7) Otherwise, increment our index into field_pages and draw some more
(returning to step 4), until there's nothing left.
It's a bit of work to set up the first time, but well worth it, because
your complex forms will be more robust than most.
miguel
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Multipage form
I find sessions to be the best solution in these situations. I like to compile the problem into a single multi-dimensional array of pages and form inputs such as.. $forms = array ( 'contact' = array ($company, $name, $email, $addr, $phone), 'creditcard' = array ($full_name, $num, $type, $confirm) ); session_register(forms); Access.. $forms[contact][0]; // $company $forms[creditcard][3]; // $cc_confirm This way there is no chance I can loose data. And there isn't anything that my visitors can do to mess it up. Set the No-cache headers at the top of each script to prevent the page expired message from appearing when your users hit the back button. You should also use the session array to repopulate fields. Do not rely on browser cache. header(Pragma: no-cache); header(Cache-Control: no-cache); -Kevin -Original Message- From: David Johansen [mailto:[EMAIL PROTECTED]] Sent: Wednesday, March 20, 2002 9:57 AM To: [EMAIL PROTECTED] Subject: [PHP] Multipage form I was just wondering what was the best way to handle a multipage form. Would the best way be to keep passing the variables through the forms as hidden values or should I use sessions and store all the values as session variables? What's the best way to handle all of this? Also the different forms will all be in the same php file that loops to itself if that makes a difference. Thanks, Dave -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
