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 2 of 3 — ← Prev page 1 [2] 3  Next page →

#2381

On Tue, 28 Jun 2011 18:58:42 -0400, in comp.lang.php Jerry Stuckle
<jstucklex@attglobal.net>
<iudmb4$168$1@dont-email.me> wrote:

>| 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.

No you can't disable the back button!!!!!
http://www.jibbering.com/faq/#disableBackButton

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

#2383

On 6/28/2011 7:30 PM, Jeff North wrote:
> On Tue, 28 Jun 2011 18:58:42 -0400, in comp.lang.php Jerry Stuckle
> <jstucklex@attglobal.net>
> <iudmb4$168$1@dont-email.me>  wrote:
>
>> | 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.
>
> No you can't disable the back button!!!!!
> http://www.jibbering.com/faq/#disableBackButton

Actually, it's quite easy to effectively disable the back button.  I do 
it quite regularly for pages where I don't want the user to be able to 
go back - like payment processing confirmation.  And no client-side 
programming such as javascript required.


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

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

#2385

On Tue, 28 Jun 2011 20:21:40 -0400, in comp.lang.php Jerry Stuckle
<jstucklex@attglobal.net>
<iudr6o$263$1@dont-email.me> wrote:

>| On 6/28/2011 7:30 PM, Jeff North wrote:
>| > On Tue, 28 Jun 2011 18:58:42 -0400, in comp.lang.php Jerry Stuckle
>| > <jstucklex@attglobal.net>
>| > <iudmb4$168$1@dont-email.me>  wrote:
>| >
>| >> | 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.
>| >
>| > No you can't disable the back button!!!!!
>| > http://www.jibbering.com/faq/#disableBackButton
>| 
>| Actually, it's quite easy to effectively disable the back button.  I do 
>| it quite regularly for pages where I don't want the user to be able to 
>| go back - like payment processing confirmation.  And no client-side 
>| programming such as javascript required.

Enlighten me. How do you disable the back button without using
JavaScript?

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

#2390

On 6/29/2011 12:52 AM, Jeff North wrote:
> On Tue, 28 Jun 2011 20:21:40 -0400, in comp.lang.php Jerry Stuckle
> <jstucklex@attglobal.net>
> <iudr6o$263$1@dont-email.me>  wrote:
>
>> | On 6/28/2011 7:30 PM, Jeff North wrote:
>> |>  On Tue, 28 Jun 2011 18:58:42 -0400, in comp.lang.php Jerry Stuckle
>> |>  <jstucklex@attglobal.net>
>> |>  <iudmb4$168$1@dont-email.me>   wrote:
>> |>
>> |>>  | 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.
>> |>
>> |>  No you can't disable the back button!!!!!
>> |>  http://www.jibbering.com/faq/#disableBackButton
>> |
>> | Actually, it's quite easy to effectively disable the back button.  I do
>> | it quite regularly for pages where I don't want the user to be able to
>> | go back - like payment processing confirmation.  And no client-side
>> | programming such as javascript required.
>
> Enlighten me. How do you disable the back button without using
> JavaScript?

By using the Location: header call to redirect the browser to the new page.

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

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

#2392

On 6/29/2011 7:59 AM, Jerry Stuckle wrote:
> On 6/29/2011 12:52 AM, Jeff North wrote:
>> Enlighten me. How do you disable the back button without using
>> JavaScript?
>
> By using the Location: header call to redirect the browser to the new page.

Jerry, can you unpack that? I can see that working when the user goes 
back, but isn't that code there when the user arrives to that page the 
first time? Or, are you checking for session variables, and if they are 
set, the location:header does not execute?

Bill B

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

#2393

On 6/29/2011 8:09 AM, Bill B wrote:
> On 6/29/2011 7:59 AM, Jerry Stuckle wrote:
>> On 6/29/2011 12:52 AM, Jeff North wrote:
>>> Enlighten me. How do you disable the back button without using
>>> JavaScript?
>>
>> By using the Location: header call to redirect the browser to the new
>> page.
>
> Jerry, can you unpack that? I can see that working when the user goes
> back, but isn't that code there when the user arrives to that page the
> first time? Or, are you checking for session variables, and if they are
> set, the location:header does not execute?
>
> Bill B
>

You obviously don't make the header location call the first time you 
access the page.  Only when the form has been submitted.

You submit the form to the same page the form is on, and process all the 
data there (a good idea anyway - that way the display and processing of 
the form are all in the same script).  Once the user has submitted the 
form and you've processed the data, use the location header to redirect 
to the next page.

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

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

#2394

On 6/29/2011 8:41 AM, Jerry Stuckle wrote:
> On 6/29/2011 8:09 AM, Bill B wrote:
>> On 6/29/2011 7:59 AM, Jerry Stuckle wrote:
>>> On 6/29/2011 12:52 AM, Jeff North wrote:
>>>> Enlighten me. How do you disable the back button without using
>>>> JavaScript?
>>>
>>> By using the Location: header call to redirect the browser to the new
>>> page.
>>
>> Jerry, can you unpack that? I can see that working when the user goes
>> back, but isn't that code there when the user arrives to that page the
>> first time? Or, are you checking for session variables, and if they are
>> set, the location:header does not execute?
>>
>> Bill B
>>
>
> You obviously don't make the header location call the first time you
> access the page. Only when the form has been submitted.
>
> You submit the form to the same page the form is on, and process all the
> data there (a good idea anyway - that way the display and processing of
> the form are all in the same script). Once the user has submitted the
> form and you've processed the data, use the location header to redirect
> to the next page.

By habit, possibly a bad one, I process forms in a separate script. For 
example, form.php is processed in form_do.php. Is that a bad idea or a 
"less good one" to your way of thinking?

Bill B

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

#2398

On 6/29/2011 8:48 AM, Bill B wrote:
> On 6/29/2011 8:41 AM, Jerry Stuckle wrote:
>> On 6/29/2011 8:09 AM, Bill B wrote:
>>> On 6/29/2011 7:59 AM, Jerry Stuckle wrote:
>>>> On 6/29/2011 12:52 AM, Jeff North wrote:
>>>>> Enlighten me. How do you disable the back button without using
>>>>> JavaScript?
>>>>
>>>> By using the Location: header call to redirect the browser to the new
>>>> page.
>>>
>>> Jerry, can you unpack that? I can see that working when the user goes
>>> back, but isn't that code there when the user arrives to that page the
>>> first time? Or, are you checking for session variables, and if they are
>>> set, the location:header does not execute?
>>>
>>> Bill B
>>>
>>
>> You obviously don't make the header location call the first time you
>> access the page. Only when the form has been submitted.
>>
>> You submit the form to the same page the form is on, and process all the
>> data there (a good idea anyway - that way the display and processing of
>> the form are all in the same script). Once the user has submitted the
>> form and you've processed the data, use the location header to redirect
>> to the next page.
>
> By habit, possibly a bad one, I process forms in a separate script. For
> example, form.php is processed in form_do.php. Is that a bad idea or a
> "less good one" to your way of thinking?
>
> Bill B

I prefer to keep everything in the same script when possible. It's 
easier to make modifications when they are all together ("more 
modular").  There are also fewer scripts to manage.

But it's also somewhat of a preference; you'll find others who say I'm 
crazy and your way is better.

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

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

#2401

On 6/29/2011 11:08 AM, Jerry Stuckle wrote:
> I prefer to keep everything in the same script when possible. It's
> easier to make modifications when they are all together ("more
> modular"). There are also fewer scripts to manage.

Thanks, Jerry. This may warrant a look-see at some revisions.

Bill B

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

#2396

On Wed, 29 Jun 2011 07:59:12 -0400, in comp.lang.php Jerry Stuckle
<jstucklex@attglobal.net>
<iuf42j$m2e$1@dont-email.me> wrote:

>| On 6/29/2011 12:52 AM, Jeff North wrote:
>| > On Tue, 28 Jun 2011 20:21:40 -0400, in comp.lang.php Jerry Stuckle
>| > <jstucklex@attglobal.net>
>| > <iudr6o$263$1@dont-email.me>  wrote:
>| >
>| >> | On 6/28/2011 7:30 PM, Jeff North wrote:
>| >> |>  On Tue, 28 Jun 2011 18:58:42 -0400, in comp.lang.php Jerry Stuckle
>| >> |>  <jstucklex@attglobal.net>
>| >> |>  <iudmb4$168$1@dont-email.me>   wrote:
>| >> |>
>| >> |>>  | 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.
>| >> |>
>| >> |>  No you can't disable the back button!!!!!
>| >> |>  http://www.jibbering.com/faq/#disableBackButton
>| >> |
>| >> | Actually, it's quite easy to effectively disable the back button.  I do
>| >> | it quite regularly for pages where I don't want the user to be able to
>| >> | go back - like payment processing confirmation.  And no client-side
>| >> | programming such as javascript required.
>| >
>| > Enlighten me. How do you disable the back button without using
>| > JavaScript?
>| 
>| By using the Location: header call to redirect the browser to the new page.

You still haven't disabled the browsers back button.

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

#2399

On 6/29/2011 9:10 AM, Jeff North wrote:
> On Wed, 29 Jun 2011 07:59:12 -0400, in comp.lang.php Jerry Stuckle
> <jstucklex@attglobal.net>
> <iuf42j$m2e$1@dont-email.me>  wrote:
>
>> | On 6/29/2011 12:52 AM, Jeff North wrote:
>> |>  On Tue, 28 Jun 2011 20:21:40 -0400, in comp.lang.php Jerry Stuckle
>> |>  <jstucklex@attglobal.net>
>> |>  <iudr6o$263$1@dont-email.me>   wrote:
>> |>
>> |>>  | On 6/28/2011 7:30 PM, Jeff North wrote:
>> |>>  |>   On Tue, 28 Jun 2011 18:58:42 -0400, in comp.lang.php Jerry Stuckle
>> |>>  |>   <jstucklex@attglobal.net>
>> |>>  |>   <iudmb4$168$1@dont-email.me>    wrote:
>> |>>  |>
>> |>>  |>>   | 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.
>> |>>  |>
>> |>>  |>   No you can't disable the back button!!!!!
>> |>>  |>   http://www.jibbering.com/faq/#disableBackButton
>> |>>  |
>> |>>  | Actually, it's quite easy to effectively disable the back button.  I do
>> |>>  | it quite regularly for pages where I don't want the user to be able to
>> |>>  | go back - like payment processing confirmation.  And no client-side
>> |>>  | programming such as javascript required.
>> |>
>> |>  Enlighten me. How do you disable the back button without using
>> |>  JavaScript?
>> |
>> | By using the Location: header call to redirect the browser to the new page.
>
> You still haven't disabled the browsers back button.

Yup.  Try it.  It doesn't work.

And I did say "effectively disable" - which is what this does.

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

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

#2402

.oO(Jerry Stuckle)

>On 6/29/2011 12:52 AM, Jeff North wrote:
>>
>> Enlighten me. How do you disable the back button without using
>> JavaScript?
>
>By using the Location: header call to redirect the browser to the new page.

This doesn't disable the back button. It may prevent double submissions
of form data by replacing the POST request with a GET in the browser's
history, but the user can still go back where he wants. Even if the
previous page might trigger an immediate redirect again, every modern
browser allows to go back more than one page at once.

So I wouldn't call that "disabled".

Micha

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

#2406

On 6/29/2011 12:56 PM, Michael Fesser wrote:
> .oO(Jerry Stuckle)
>
>> On 6/29/2011 12:52 AM, Jeff North wrote:
>>>
>>> Enlighten me. How do you disable the back button without using
>>> JavaScript?
>>
>> By using the Location: header call to redirect the browser to the new page.
>
> This doesn't disable the back button. It may prevent double submissions
> of form data by replacing the POST request with a GET in the browser's
> history, but the user can still go back where he wants. Even if the
> previous page might trigger an immediate redirect again, every modern
> browser allows to go back more than one page at once.
>
> So I wouldn't call that "disabled".
>
> Micha

Micha, if you check back, I said "effectively disable" - which it does.

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

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

#2373

On Mon, 27 Jun 2011 18:01:21 -0400, 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.
>
> 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.

If the circumstance you're concerned about is (for example) a 3-page
form, a user being on page 2, entering data in a few fields, flipping
back to page one, flipping forward to page 2 again and the concern is
about whether the previous page-2 fields still have the entered data or
not, don't worry about it. It's all under the brower's control anyway.
If the user uses the page-forward button, the entered data will
*probably* still be there, but there's nothing you can do to control it
either way. If the user uses the "next page"/html submit button to go
forward, the entered data will probably *not* be there, but in this
case, you *still* can't do anything about it. And we're not even getting
into the whole molassas vat of what happens if the user changes
something and then uses those two different means of navigation...

Even the use of the javascript events doesn't necessarily fix the
behavior to one thing or the other, as web pages are *supposed to be*
fairly agnostic as to user agent. Not all user agents have javascript,
not all have it turned on, not all have complete implementations of
those events even if they do. (EG: some versions of Firefox trigger
.unload on a tab close, and trigger .load on a tab restore. Some don't.)

Short answer: PHP can't make a browser into a complex client interface
engine. It just won't work. Can't make a silk purse out of a pig's ear
either.

-- 
29. I will dress in bright and cheery colors, and so throw my enemies 
   into confusion.
        --Peter Anspach's list of things to do as an Evil Overlord

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

#2378

On Mon, 27 Jun 2011 12:40:47 -0400, in comp.lang.php William Gill
<noreply@domain.invalid>
<iuabqa$530$1@dont-email.me> 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?

Do you inputs actually require multiple pages?
Have you thought about using a tabbed interface in a single html file?

The concern with this type of page is the session may timeout before
the user has a chance to complete the form.

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

#2380

On 6/28/2011 6:46 PM, Jeff North wrote:

> Have you thought about using a tabbed interface in a single html file?
>
> The concern with this type of page is the session may timeout before
> the user has a chance to complete the form.

Actually no I hadn't, but as you say session timeout may be a problem.

Or is it?

If the information is stored in the browser until the user says "OK, I'm 
done!" (clicks submit, or whatever mechanism), and there is no need to 
retain info from a previous page, session variables wouldn't be needed.

Then again, there's still the problem of a user clicking "back" either 
on purpose, or by mistakenly clicking "back" instead of a tab.

(don't mind me, I frequently have these arguments with myself)

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

#2386

On Tue, 28 Jun 2011 19:29:27 -0400, in comp.lang.php William Gill
<nospam@domain.invalid>
<iudo57$5bq$1@dont-email.me> wrote:

>| On 6/28/2011 6:46 PM, Jeff North wrote:
>| 
>| > Have you thought about using a tabbed interface in a single html file?
>| >
>| > The concern with this type of page is the session may timeout before
>| > the user has a chance to complete the form.

Another problem that I thought of after I posted this. The tabbed
interface will need to be JavaScript driven so if JS is disabled then
no-go (although you could make it just one huge continuous form).
 
>| Actually no I hadn't, but as you say session timeout may be a problem.
>| 
>| Or is it?
>| 
>| If the information is stored in the browser until the user says "OK, I'm 
>| done!" (clicks submit, or whatever mechanism), and there is no need to 
>| retain info from a previous page, session variables wouldn't be needed.
>|
>| Then again, there's still the problem of a user clicking "back" either 
>| on purpose, or by mistakenly clicking "back" instead of a tab.

If the user hits the back button then they will be returned to the
previous page (as expected). If they then hit the forward button they
will be returned to the data entry page (as expected). With this type
of navigation the browser usually fetches the information from cache.
If cache isn't used then the user will get the message do the want to
refresh the page and loose all of their data inputs :-)
 
>| (don't mind me, I frequently have these arguments with myself)

As long as they remain verbal arguments then you should be fine :-P

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

#2391

On 6/29/2011 1:15 AM, Jeff North wrote:
> On Tue, 28 Jun 2011 19:29:27 -0400, in comp.lang.php William Gill
> <nospam@domain.invalid>
> <iudo57$5bq$1@dont-email.me>  wrote:
>
>> | On 6/28/2011 6:46 PM, Jeff North wrote:
>> |
>> |>  Have you thought about using a tabbed interface in a single html file?
>> |>
>> |>  The concern with this type of page is the session may timeout before
>> |>  the user has a chance to complete the form.
>
> Another problem that I thought of after I posted this. The tabbed
> interface will need to be JavaScript driven so if JS is disabled then
> no-go (although you could make it just one huge continuous form).
>
>> | Actually no I hadn't, but as you say session timeout may be a problem.
>> |
>> | Or is it?
>> |
>> | If the information is stored in the browser until the user says "OK, I'm
>> | done!" (clicks submit, or whatever mechanism), and there is no need to
>> | retain info from a previous page, session variables wouldn't be needed.
>> |
>> | Then again, there's still the problem of a user clicking "back" either
>> | on purpose, or by mistakenly clicking "back" instead of a tab.
>
> If the user hits the back button then they will be returned to the
> previous page (as expected). If they then hit the forward button they
> will be returned to the data entry page (as expected). With this type
> of navigation the browser usually fetches the information from cache.
> If cache isn't used then the user will get the message do the want to
> refresh the page and loose all of their data inputs :-)
>

Not if you fill the form in from the $_SESSION array, as I suggested. 
When you hit the back button the data will still appear, even if the 
page wasn't in the cache.

>> | (don't mind me, I frequently have these arguments with myself)
>
> As long as they remain verbal arguments then you should be fine :-P


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

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

#2403

.oO(Jeff North)

>Another problem that I thought of after I posted this. The tabbed
>interface will need to be JavaScript driven so if JS is disabled then
>no-go (although you could make it just one huge continuous form).

That's how it should be. The tabs should be generated with JS, so that
if no JS is available, all form fields appear at once.

Micha

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

#2404

.oO(William Gill)

>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).

Why should they fill out a form page and then, instead of submitting it,
hit the back button? And if they do, it's their problem I think.

Every 'next' button on the form pages should be a submit button and send
the data from the current page to the server, where it's stored in a
session. After such a submit the user can change to any previous page as
he wants, because the data is already stored on the server.

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

Ugly, unreliable and IMHO completely unnecessary.

Micha

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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

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

csiph-web