|
|
Posted by Jack Jackson on 10/19/45 11:22
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
>
>
Navigation:
[Reply to this message]
|