Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.php > #2353 > unrolled thread

multi-page form

Back to article view | Back to comp.lang.php

Contents

  multi-page form William Gill <noreply@domain.invalid> - 2011-06-27 12:40 -0400
    Re: multi-page form Bill B <me@privacy.net> - 2011-06-27 13:31 -0400
      Re: multi-page form William Gill <noreply@domain.invalid> - 2011-06-27 13:41 -0400
        Re: multi-page form Bill B <me@privacy.net> - 2011-06-27 14:24 -0400
    Re: multi-page form Jerry Stuckle <jstucklex@attglobal.net> - 2011-06-27 17:32 -0400
      Re: multi-page form William Gill <nospam@domain.invalid> - 2011-06-27 18:01 -0400
        Re: multi-page form Bill B <me@privacy.net> - 2011-06-27 18:18 -0400
          Re: multi-page form Graham Hobbs <ghobbs@cdpwise.net> - 2011-07-05 20:06 -0400
        Re: multi-page form Jerry Stuckle <jstucklex@attglobal.net> - 2011-06-27 18:54 -0400
          Re: multi-page form William Gill <nospam@domain.invalid> - 2011-06-28 04:22 -0400
            Re: multi-page form Jerry Stuckle <jstucklex@attglobal.net> - 2011-06-28 06:53 -0400
              Re: multi-page form William Gill <nospam@domain.invalid> - 2011-06-28 12:13 -0400
                Re: multi-page form Bill B <me@privacy.net> - 2011-06-28 14:00 -0400
                  Re: multi-page form Jerry Stuckle <jstucklex@attglobal.net> - 2011-06-28 15:02 -0400
                    Re: multi-page form Bill B <me@privacy.net> - 2011-06-28 15:06 -0400
                    Re: multi-page form Bill B <me@privacy.net> - 2011-06-28 15:46 -0400
                      Re: multi-page form William Gill <nospam@domain.invalid> - 2011-06-28 16:05 -0400
                        Re: multi-page form Bill B <me@privacy.net> - 2011-06-28 16:12 -0400
                        Re: multi-page form Bill B <me@privacy.net> - 2011-06-28 16:20 -0400
                      Re: multi-page form Jerry Stuckle <jstucklex@attglobal.net> - 2011-06-28 18:58 -0400
                        Re: multi-page form Jeff North <jnorthau@yahoo.com.au> - 2011-06-29 09:30 +1000
                          Re: multi-page form Jerry Stuckle <jstucklex@attglobal.net> - 2011-06-28 20:21 -0400
                            Re: multi-page form Jeff North <jnorthau@yahoo.com.au> - 2011-06-29 14:52 +1000
                              Re: multi-page form Jerry Stuckle <jstucklex@attglobal.net> - 2011-06-29 07:59 -0400
                                Re: multi-page form Bill B <me@privacy.net> - 2011-06-29 08:09 -0400
                                  Re: multi-page form Jerry Stuckle <jstucklex@attglobal.net> - 2011-06-29 08:41 -0400
                                    Re: multi-page form Bill B <me@privacy.net> - 2011-06-29 08:48 -0400
                                      Re: multi-page form Jerry Stuckle <jstucklex@attglobal.net> - 2011-06-29 11:08 -0400
                                        Re: multi-page form Bill B <me@privacy.net> - 2011-06-29 12:27 -0400
                                Re: multi-page form Jeff North <jnorthau@yahoo.com.au> - 2011-06-29 23:10 +1000
                                  Re: multi-page form Jerry Stuckle <jstucklex@attglobal.net> - 2011-06-29 11:09 -0400
                                Re: multi-page form Michael Fesser <netizen@gmx.de> - 2011-06-29 18:56 +0200
                                  Re: multi-page form Jerry Stuckle <jstucklex@attglobal.net> - 2011-06-29 15:32 -0400
        Re: multi-page form "Peter H. Coffin" <hellsop@ninehells.com> - 2011-06-28 13:57 -0500
    Re: multi-page form Jeff North <jnorthau@yahoo.com.au> - 2011-06-29 08:46 +1000
      Re: multi-page form William Gill <nospam@domain.invalid> - 2011-06-28 19:29 -0400
        Re: multi-page form Jeff North <jnorthau@yahoo.com.au> - 2011-06-29 15:15 +1000
          Re: multi-page form Jerry Stuckle <jstucklex@attglobal.net> - 2011-06-29 08:01 -0400
          Re: multi-page form Michael Fesser <netizen@gmx.de> - 2011-06-29 19:00 +0200
    Re: multi-page form Michael Fesser <netizen@gmx.de> - 2011-06-29 19:05 +0200
      Re: multi-page form William Gill <nospam@domain.invalid> - 2011-06-29 13:44 -0400

Page 1 of 3  [1] 2 3  Next page →

#2353 — multi-page form

I am working on a form that will traverse many pages (lots of context 
and a few inputs on each page).  My concern is the user navigating back 
and forth between pages w/o losing data (i.e. via the back button).

As far as I can tell, I need to integrate ECMA script, XMLHttpRequest, 
and session variables, triggered by the onLoad and onUnload events.

Are there any other approaches that I should look into?

[toc] | [next] | [standalone]

#2354

On 6/27/2011 12:40 PM, William Gill wrote:
> I am working on a form that will traverse many pages (lots of context
> and a few inputs on each page). My concern is the user navigating back
> and forth between pages w/o losing data (i.e. via the back button).
>
> As far as I can tell, I need to integrate ECMA script, XMLHttpRequest,
> and session variables, triggered by the onLoad and onUnload events.
>
> Are there any other approaches that I should look into?

Once the values of the form have been processed, assign them to session 
variables, which will survive from page to page so long as the session 
has not been unset or destroyed. On each page set $someformvar = 
$_SESSION['someformvarvalue']. The fields in the form can be populated 
with the value of the session variables using something like 
value="<?php echo $someformvar ?>".

Bill B

[toc] | [prev] | [next] | [standalone]

#2355

On 6/27/2011 1:31 PM, Bill B wrote:
> Once the values of the form have been processed, assign them to session
> variables, which will survive from page to page so long as the session
> has not been unset or destroyed. On each page set $someformvar =
> $_SESSION['someformvarvalue']. The fields in the form can be populated
> with the value of the session variables using something like
> value="<?php echo $someformvar ?>".

You may be missing my point.  I know how to set and get session 
variables, but I need to insure "the values of the form have been 
processed" if the user hits the back button, or otherwise returns to a 
previous form page.

[toc] | [prev] | [next] | [standalone]

#2356

On 6/27/2011 1:41 PM, William Gill wrote:
> On 6/27/2011 1:31 PM, Bill B wrote:
>> Once the values of the form have been processed, assign them to session
>> variables, which will survive from page to page so long as the session
>> has not been unset or destroyed. On each page set $someformvar =
>> $_SESSION['someformvarvalue']. The fields in the form can be populated
>> with the value of the session variables using something like
>> value="<?php echo $someformvar ?>".
>
> You may be missing my point. I know how to set and get session
> variables, but I need to insure "the values of the form have been
> processed" if the user hits the back button, or otherwise returns to a
> previous form page.

Does each page have its own submit button? If so, pressing the submit 
button will process the form on that page. While hitting the back button 
on the browser has its own set of problems, it doesn't unprocess the 
page, but the page could be reprocessed if the user hits the submit 
button again.

You could display the form dynamically, and if the user goes backward, 
and if the form was posted and field session variables are already set, 
you can dispay an error or warning, then send them on to the next 
page/form that should be completed and processed.

Bill B

[toc] | [prev] | [next] | [standalone]

#2360

On 6/27/2011 12:40 PM, William Gill wrote:
> I am working on a form that will traverse many pages (lots of context
> and a few inputs on each page). My concern is the user navigating back
> and forth between pages w/o losing data (i.e. via the back button).
>
> As far as I can tell, I need to integrate ECMA script, XMLHttpRequest,
> and session variables, triggered by the onLoad and onUnload events.
>
> Are there any other approaches that I should look into?

What are you trying to do?  Keep the user from going back a page?  If 
they do, the client may not even request the page from the server - just 
serve it from the client cache.

Do you want to prevent the user from going back a page?  Force the page 
to be reloaded if they do go back?  What's your goal?

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#2361

On 6/27/2011 5:32 PM, Jerry Stuckle wrote:
> On 6/27/2011 12:40 PM, William Gill wrote:
>> I am working on a form that will traverse many pages (lots of context
>> and a few inputs on each page). My concern is the user navigating back
>> and forth between pages w/o losing data (i.e. via the back button).
>>
>> As far as I can tell, I need to integrate ECMA script, XMLHttpRequest,
>> and session variables, triggered by the onLoad and onUnload events.
>>
>> Are there any other approaches that I should look into?
>
> What are you trying to do? Keep the user from going back a page? If they
> do, the client may not even request the page from the server - just
> serve it from the client cache.
>
> Do you want to prevent the user from going back a page? Force the page
> to be reloaded if they do go back? What's your goal?
>
No I wouldn't prevent them from going back and forth even if I could.

There are as few as 4 or 5 fields on some pages, but they may need/want 
to back up to see their earlier input.

All I want is to prevent them from completing some fields; then backing 
up and losing their input.

I'm thinking of  creating an XMLHttpRequest object and using it to 
update session variables if a user backs up (triggered by the ONUNLOAD 
event),and then repopulating the fields when he/she returns (ONLOAD).

Haven't done it in a while, and wanted to know if this is the best approach.

[toc] | [prev] | [next] | [standalone]

#2362

On 6/27/2011 6:01 PM, William Gill wrote:
> There are as few as 4 or 5 fields on some pages, but they may need/want
> to back up to see their earlier input.

Why not provide a running summary of information that has already been 
entered, eliminating, or at least reducing, the need to back track?

Bill B

[toc] | [prev] | [next] | [standalone]

#2456

On Mon, 27 Jun 2011 18:18:46 -0400, Bill B <me@privacy.net> wrote:

>On 6/27/2011 6:01 PM, William Gill wrote:
>> There are as few as 4 or 5 fields on some pages, but they may need/want
>> to back up to see their earlier input.
>
>Why not provide a running summary of information that has already been 
>entered, eliminating, or at least reducing, the need to back track?
>
>Bill B
That lot was quite interesting; have just finished a great cut and
paste session to achieve such, think that's what you're saying,
Graham H 

[toc] | [prev] | [next] | [standalone]

#2364

On 6/27/2011 6:01 PM, William Gill wrote:
> On 6/27/2011 5:32 PM, Jerry Stuckle wrote:
>> On 6/27/2011 12:40 PM, William Gill wrote:
>>> I am working on a form that will traverse many pages (lots of context
>>> and a few inputs on each page). My concern is the user navigating back
>>> and forth between pages w/o losing data (i.e. via the back button).
>>>
>>> As far as I can tell, I need to integrate ECMA script, XMLHttpRequest,
>>> and session variables, triggered by the onLoad and onUnload events.
>>>
>>> Are there any other approaches that I should look into?
>>
>> What are you trying to do? Keep the user from going back a page? If they
>> do, the client may not even request the page from the server - just
>> serve it from the client cache.
>>
>> Do you want to prevent the user from going back a page? Force the page
>> to be reloaded if they do go back? What's your goal?
>>
> No I wouldn't prevent them from going back and forth even if I could.
>
> There are as few as 4 or 5 fields on some pages, but they may need/want
> to back up to see their earlier input.
>
> All I want is to prevent them from completing some fields; then backing
> up and losing their input.
>
> I'm thinking of creating an XMLHttpRequest object and using it to update
> session variables if a user backs up (triggered by the ONUNLOAD
> event),and then repopulating the fields when he/she returns (ONLOAD).
>
> Haven't done it in a while, and wanted to know if this is the best
> approach.
>

 From the PHP end, it's not that hard.  When they enter data, place it 
in the $_SESSION array.  When you display a page, check to see if the 
entries have already been saved in the $_SESSION array.  If they have, 
display the previously entered values.  If not, display an empty field 
or other default value.

If you want to use AJAX or other javascript code, you're asking in the 
wrong newsgroup.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#2366

On 6/27/2011 6:54 PM, Jerry Stuckle wrote:
>  From the PHP end, it's not that hard. When they enter data, place it in
> the $_SESSION array. When you display a page, check to see if the
> entries have already been saved in the $_SESSION array. If they have,
> display the previously entered values. If not, display an empty field or
> other default value.
Agreed, pretty straight forward.

> If you want to use AJAX or other javascript code, you're asking in the
> wrong newsgroup.
If I asked in a JavaScript newsgroup I'd get JavaScript answers, and 
wouldn't get any alternative suggestions.  I asked here because the 
constant is PHP (i.e. a something & PHP solution) and the browser side 
of things might not be limited to AJAX/JavaScript.  Or to put it another 
way, I'm asking in a PHP newsgroup "what else works with PHP to do what 
I'm asking"

[toc] | [prev] | [next] | [standalone]

#2367

On 6/28/2011 4:22 AM, William Gill wrote:
> On 6/27/2011 6:54 PM, Jerry Stuckle wrote:
>> From the PHP end, it's not that hard. When they enter data, place it in
>> the $_SESSION array. When you display a page, check to see if the
>> entries have already been saved in the $_SESSION array. If they have,
>> display the previously entered values. If not, display an empty field or
>> other default value.
> Agreed, pretty straight forward.
>

It's not hard, and pretty standard.

>> If you want to use AJAX or other javascript code, you're asking in the
>> wrong newsgroup.
> If I asked in a JavaScript newsgroup I'd get JavaScript answers, and
> wouldn't get any alternative suggestions. I asked here because the
> constant is PHP (i.e. a something & PHP solution) and the browser side
> of things might not be limited to AJAX/JavaScript. Or to put it another
> way, I'm asking in a PHP newsgroup "what else works with PHP to do what
> I'm asking"
>
>

I understood why you asked here.  Just giving you a pointer to another 
newsgroup if you want a different solution.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#2369

On 6/28/2011 6:53 AM, Jerry Stuckle wrote:
> On 6/28/2011 4:22 AM, William Gill wrote:
>> On 6/27/2011 6:54 PM, Jerry Stuckle wrote:
>>> From the PHP end, it's not that hard. When they enter data, place it in
>>> the $_SESSION array. When you display a page, check to see if the
>>> entries have already been saved in the $_SESSION array. If they have,
>>> display the previously entered values. If not, display an empty field or
>>> other default value.
>> Agreed, pretty straight forward.
>>
>
> It's not hard, and pretty standard.
>
>>> If you want to use AJAX or other javascript code, you're asking in the
>>> wrong newsgroup.
>> If I asked in a JavaScript newsgroup I'd get JavaScript answers, and
>> wouldn't get any alternative suggestions. I asked here because the
>> constant is PHP (i.e. a something & PHP solution) and the browser side
>> of things might not be limited to AJAX/JavaScript. Or to put it another
>> way, I'm asking in a PHP newsgroup "what else works with PHP to do what
>> I'm asking"
>>
>>
>
> I understood why you asked here. Just giving you a pointer to another
> newsgroup if you want a different solution.
>
Don't know what I was really expecting to find.  Guess I'll just go the 
ECMA script (JavaScript); XMLHttpRequest and session variable route.

[toc] | [prev] | [next] | [standalone]

#2370

On 6/28/2011 12:13 PM, William Gill wrote:
> Don't know what I was really expecting to find. Guess I'll just go the
> ECMA script (JavaScript); XMLHttpRequest and session variable route.

If the issue is users pressing the back button to look at previously 
entered data, revisit the idea of providing the cumulative information 
that has been entered, thus taking away the need to go back. Once 
posted, the data can be placed in session variables and will follow the 
user as s/he goes from page/form to page/form. This eliminates the need 
for a complex coding solution.

Bill B

[toc] | [prev] | [next] | [standalone]

#2371

On 6/28/2011 2:00 PM, Bill B wrote:
> On 6/28/2011 12:13 PM, William Gill wrote:
>> Don't know what I was really expecting to find. Guess I'll just go the
>> ECMA script (JavaScript); XMLHttpRequest and session variable route.
>
> If the issue is users pressing the back button to look at previously
> entered data, revisit the idea of providing the cumulative information
> that has been entered, thus taking away the need to go back. Once
> posted, the data can be placed in session variables and will follow the
> user as s/he goes from page/form to page/form. This eliminates the need
> for a complex coding solution.
>
> Bill B
>
>

Saving the data in the $_SESSION array and displaying it if it exists 
isn't really a "complex coding solution".  Plus the user can then go 
back and change a response if necessary.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#2372

On 6/28/2011 3:02 PM, Jerry Stuckle wrote:
> On 6/28/2011 2:00 PM, Bill B wrote:
>> On 6/28/2011 12:13 PM, William Gill wrote:
>>> Don't know what I was really expecting to find. Guess I'll just go the
>>> ECMA script (JavaScript); XMLHttpRequest and session variable route.
>>
>> If the issue is users pressing the back button to look at previously
>> entered data, revisit the idea of providing the cumulative information
>> that has been entered, thus taking away the need to go back. Once
>> posted, the data can be placed in session variables and will follow the
>> user as s/he goes from page/form to page/form. This eliminates the need
>> for a complex coding solution.
>>
>> Bill B
>>
>>
>
> Saving the data in the $_SESSION array and displaying it if it exists
> isn't really a "complex coding solution". Plus the user can then go back
> and change a response if necessary.

Agreed. I was responding more to the OP's inclination to go down the 
path of JavaScript and other options he mentioned. Your point about 
session variables seems straightforward to me.

Bill B

[toc] | [prev] | [next] | [standalone]

#2374

On 6/28/2011 3:02 PM, Jerry Stuckle wrote:
> On 6/28/2011 2:00 PM, Bill B wrote:
>> On 6/28/2011 12:13 PM, William Gill wrote:
>>> Don't know what I was really expecting to find. Guess I'll just go the
>>> ECMA script (JavaScript); XMLHttpRequest and session variable route.
>>
>> If the issue is users pressing the back button to look at previously
>> entered data, revisit the idea of providing the cumulative information
>> that has been entered, thus taking away the need to go back. Once
>> posted, the data can be placed in session variables and will follow the
>> user as s/he goes from page/form to page/form. This eliminates the need
>> for a complex coding solution.
>>
>> Bill B
>>
>>
>
> Saving the data in the $_SESSION array and displaying it if it exists
> isn't really a "complex coding solution". Plus the user can then go back
> and change a response if necessary.

Would you not be inclined to offer the user a submit button to give some 
control over going backwards rather than force the user to use the 
browser back button?

Bill

[toc] | [prev] | [next] | [standalone]

#2375

On 6/28/2011 3:46 PM, Bill B wrote:
> On 6/28/2011 3:02 PM, Jerry Stuckle wrote:
>> On 6/28/2011 2:00 PM, Bill B wrote:
>>> On 6/28/2011 12:13 PM, William Gill wrote:
>>>> Don't know what I was really expecting to find. Guess I'll just go the
>>>> ECMA script (JavaScript); XMLHttpRequest and session variable route.
>>>
>>> If the issue is users pressing the back button to look at previously
>>> entered data, revisit the idea of providing the cumulative information
>>> that has been entered, thus taking away the need to go back. Once
>>> posted, the data can be placed in session variables and will follow the
>>> user as s/he goes from page/form to page/form. This eliminates the need
>>> for a complex coding solution.
>>>
>>> Bill B
>>>
>>>
>>
>> Saving the data in the $_SESSION array and displaying it if it exists
>> isn't really a "complex coding solution". Plus the user can then go back
>> and change a response if necessary.
>
> Would you not be inclined to offer the user a submit button to give some
> control over going backwards rather than force the user to use the
> browser back button?
>
> Bill

Bill, I appreciate you effort, but the issue was never to "force" anyone 
to hit the back button.  It was to prevent data fubar not if, but WHEN 
they hit the back button.

As for "providing the cumulative information" if the initial 
questionnaire required that as few as 4 fields appear on a single page, 
do you think that displaying cumulative responses will actually help 
things overall?

I design like I ride my Harley.  If I led a driver do something stupid, 
and I'm not prepared, I'm the one who pays.

[toc] | [prev] | [next] | [standalone]

#2376

On 6/28/2011 4:05 PM, William Gill wrote:
> Bill, I appreciate you effort, but the issue was never to "force" anyone
> to hit the back button. It was to prevent data fubar not if, but WHEN
> they hit the back button.
>
> As for "providing the cumulative information" if the initial
> questionnaire required that as few as 4 fields appear on a single page,
> do you think that displaying cumulative responses will actually help
> things overall?
>
> I design like I ride my Harley. If I led a driver do something stupid,
> and I'm not prepared, I'm the one who pays.

I did not mean that as pointedly as that. I meant force in the sense of 
offering no other option. So, having a submit button that takes them 
back provides an option to using the browser back button.

Bill B

P.S. Nice ride.

[toc] | [prev] | [next] | [standalone]

#2377

On 6/28/2011 4:05 PM, William Gill wrote:
> As for "providing the cumulative information" if the initial
> questionnaire required that as few as 4 fields appear on a single page,
> do you think that displaying cumulative responses will actually help
> things overall?

Not knowing the total amount of information that you are working with, 
your doubts may be well founded. My idea was that if the cumulative 
responses were available on each successive page/form, at least for that 
reason the user would have no need to return to a prior page/form to see 
what had been entered. I thought that is what you noted as a reason the 
user might page back, though I may have missed the mark on understanding 
that.

Bill B

[toc] | [prev] | [next] | [standalone]

#2379

On 6/28/2011 3:46 PM, Bill B wrote:
> On 6/28/2011 3:02 PM, Jerry Stuckle wrote:
>> On 6/28/2011 2:00 PM, Bill B wrote:
>>> On 6/28/2011 12:13 PM, William Gill wrote:
>>>> Don't know what I was really expecting to find. Guess I'll just go the
>>>> ECMA script (JavaScript); XMLHttpRequest and session variable route.
>>>
>>> If the issue is users pressing the back button to look at previously
>>> entered data, revisit the idea of providing the cumulative information
>>> that has been entered, thus taking away the need to go back. Once
>>> posted, the data can be placed in session variables and will follow the
>>> user as s/he goes from page/form to page/form. This eliminates the need
>>> for a complex coding solution.
>>>
>>> Bill B
>>>
>>>
>>
>> Saving the data in the $_SESSION array and displaying it if it exists
>> isn't really a "complex coding solution". Plus the user can then go back
>> and change a response if necessary.
>
> Would you not be inclined to offer the user a submit button to give some
> control over going backwards rather than force the user to use the
> browser back button?
>
> Bill

Users are already familiar with the operation of the back button.  Why 
force them to change to something abnormal?  And even if you do, they'll 
still press the back button...

Of course, you can effectively disable the back button - at the risk of 
needlessly aggravating your users.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.php

csiph-web