Jack Jackson" <jackson.linux@xxxxxxxxx> wrote in message news:42E8D1F2.6030104@xxxxxxxxxxxx > 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: 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
