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
