| multi-page form [message #174677] |
Mon, 27 June 2011 16:40  |
William Gill
Messages: 31
Registered: March 2011
Karma: 0
|
Member |
|
|
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?
|
|
|
|
| Re: multi-page form [message #174678 is a reply to message #174677] |
Mon, 27 June 2011 17:31  |
me
Messages: 192
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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
|
|
|
|
| Re: multi-page form [message #174679 is a reply to message #174678] |
Mon, 27 June 2011 17:41 |
William Gill
Messages: 31
Registered: March 2011
Karma: 0
|
Member |
|
|
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.
|
|
|
|
| Re: multi-page form [message #174680 is a reply to message #174679] |
Mon, 27 June 2011 18:24 |
me
Messages: 192
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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
|
|
|
|
| Re: multi-page form [message #174684 is a reply to message #174677] |
Mon, 27 June 2011 21:32 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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(at)attglobal(dot)net
==================
|
|
|
|
| Re: multi-page form [message #174685 is a reply to message #174684] |
Mon, 27 June 2011 22:01 |
William Gill
Messages: 31
Registered: March 2011
Karma: 0
|
Member |
|
|
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.
|
|
|
|
| Re: multi-page form [message #174686 is a reply to message #174685] |
Mon, 27 June 2011 22:18 |
me
Messages: 192
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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
|
|
|
|
| Re: multi-page form [message #174688 is a reply to message #174685] |
Mon, 27 June 2011 22:54 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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(at)attglobal(dot)net
==================
|
|
|
|
| Re: multi-page form [message #174690 is a reply to message #174688] |
Tue, 28 June 2011 08:22 |
William Gill
Messages: 31
Registered: March 2011
Karma: 0
|
Member |
|
|
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"
|
|
|
|
| Re: multi-page form [message #174691 is a reply to message #174690] |
Tue, 28 June 2011 10:53 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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(at)attglobal(dot)net
==================
|
|
|
|
| Re: multi-page form [message #174693 is a reply to message #174691] |
Tue, 28 June 2011 16:13 |
William Gill
Messages: 31
Registered: March 2011
Karma: 0
|
Member |
|
|
Path: textnews.cambrium.nl!feeder1.cambriumusenet.nl!feed.tweaknews.nl!193.201.14 7.68.MISMATCH!feeder.news-service.com!feeder.news-service.com!85.214.198.2. MISMATCH!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for -mail
From: William Gill <nospam(at)domain(dot)invalid>
Newsgroups: comp.lang.php
Subject: Re: multi-page form
Date: Tue, 28 Jun 2011 12:13:25 -0400
Organization: A noiseless patient Spider
Lines: 29
Message-ID: <iucujl$av5$1(at)dont-email(dot)me>
References: <iuabqa$530$1(at)dont-email(dot)me> <iuasu2$6lc$1(at)dont-email(dot)me> <iuaujv$c7t$1(at)dont-email(dot)me> <iub1ml$55u$1(at)dont-email(dot)me> <iuc30m$k53$1(at)dont-email(dot)me> <iucbr3$boh$1(at)dont-email(dot)me>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 28 Jun 2011 16:13:41 +0000 (UTC)
Injection-Info: mx04.eternal-september.org; posting-host="mf7S62mQJJ6d6SHhM+yw3w";
logging-data="11237"; mail-complaints-to="abuse(at)eternal-september(dot)org"; posting-account="U2FsdGVkX1/xH4AmmtSS8Ub8XJpLZPxp"
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11
In-Reply-To: <iucbr3$boh$1(at)dont-email(dot)me>
Cancel-Lock: sha1:lJsqEvN+IOiZHp2NSt4W/o5aWRY=
Xref: textnews.cambrium.nl comp.lang.php:133952
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.
|
|
|
|
| Re: multi-page form [message #174694 is a reply to message #174693] |
Tue, 28 June 2011 18:00 |
me
Messages: 192
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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
|
|
|
|
| Re: multi-page form [message #174695 is a reply to message #174694] |
Tue, 28 June 2011 19:02 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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(at)attglobal(dot)net
==================
|
|
|
|
| Re: multi-page form [message #174696 is a reply to message #174695] |
Tue, 28 June 2011 19:06 |
me
Messages: 192
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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
|
|
|
|
| Re: multi-page form [message #174697 is a reply to message #174685] |
Tue, 28 June 2011 18:57 |
Peter H. Coffin
Messages: 245
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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
|
|
|
|
| Re: multi-page form [message #174698 is a reply to message #174695] |
Tue, 28 June 2011 19:46 |
me
Messages: 192
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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
|
|
|
|
| Re: multi-page form [message #174699 is a reply to message #174698] |
Tue, 28 June 2011 20:05 |
William Gill
Messages: 31
Registered: March 2011
Karma: 0
|
Member |
|
|
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.
|
|
|
|
| Re: multi-page form [message #174700 is a reply to message #174699] |
Tue, 28 June 2011 20:12 |
me
Messages: 192
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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.
|
|
|
|
| Re: multi-page form [message #174701 is a reply to message #174699] |
Tue, 28 June 2011 20:20 |
me
Messages: 192
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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
|
|
|
|
| Re: multi-page form [message #174702 is a reply to message #174677] |
Tue, 28 June 2011 22:46 |
Jeff North
Messages: 58
Registered: November 2010
Karma: 0
|
Member |
|
|
On Mon, 27 Jun 2011 12:40:47 -0400, in comp.lang.php William Gill
<noreply(at)domain(dot)invalid>
<iuabqa$530$1(at)dont-email(dot)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.
|
|
|
|
| Re: multi-page form [message #174703 is a reply to message #174698] |
Tue, 28 June 2011 22:58 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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(at)attglobal(dot)net
==================
|
|
|
|
| Re: multi-page form [message #174704 is a reply to message #174702] |
Tue, 28 June 2011 23:29 |
William Gill
Messages: 31
Registered: March 2011
Karma: 0
|
Member |
|
|
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)
|
|
|
|
| Re: multi-page form [message #174705 is a reply to message #174703] |
Tue, 28 June 2011 23:30 |
Jeff North
Messages: 58
Registered: November 2010
Karma: 0
|
Member |
|
|
On Tue, 28 Jun 2011 18:58:42 -0400, in comp.lang.php Jerry Stuckle
<jstucklex(at)attglobal(dot)net>
<iudmb4$168$1(at)dont-email(dot)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
|
|
|
|
| Re: multi-page form [message #174707 is a reply to message #174705] |
Wed, 29 June 2011 00:21 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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(at)attglobal(dot)net>
> <iudmb4$168$1(at)dont-email(dot)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(at)attglobal(dot)net
==================
|
|
|
|
| Re: multi-page form [message #174709 is a reply to message #174707] |
Wed, 29 June 2011 04:52 |
Jeff North
Messages: 58
Registered: November 2010
Karma: 0
|
Member |
|
|
On Tue, 28 Jun 2011 20:21:40 -0400, in comp.lang.php Jerry Stuckle
<jstucklex(at)attglobal(dot)net>
<iudr6o$263$1(at)dont-email(dot)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(at)attglobal(dot)net>
> | > <iudmb4$168$1(at)dont-email(dot)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?
|
|
|
|
| Re: multi-page form [message #174710 is a reply to message #174704] |
Wed, 29 June 2011 05:15 |
Jeff North
Messages: 58
Registered: November 2010
Karma: 0
|
Member |
|
|
On Tue, 28 Jun 2011 19:29:27 -0400, in comp.lang.php William Gill
<nospam(at)domain(dot)invalid>
<iudo57$5bq$1(at)dont-email(dot)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
|
|
|
|
| Re: multi-page form [message #174711 is a reply to message #174709] |
Wed, 29 June 2011 11:59 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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(at)attglobal(dot)net>
> <iudr6o$263$1(at)dont-email(dot)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(at)attglobal(dot)net>
>> |> <iudmb4$168$1(at)dont-email(dot)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(at)attglobal(dot)net
==================
|
|
|
|
| Re: multi-page form [message #174712 is a reply to message #174710] |
Wed, 29 June 2011 12:01 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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(at)domain(dot)invalid>
> <iudo57$5bq$1(at)dont-email(dot)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(at)attglobal(dot)net
==================
|
|
|
|
| Re: multi-page form [message #174713 is a reply to message #174711] |
Wed, 29 June 2011 12:09 |
me
Messages: 192
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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
|
|
|
|
| Re: multi-page form [message #174714 is a reply to message #174713] |
Wed, 29 June 2011 12:41 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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(at)attglobal(dot)net
==================
|
|
|
|
| Re: multi-page form [message #174715 is a reply to message #174714] |
Wed, 29 June 2011 12:48 |
me
Messages: 192
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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
|
|
|
|
| Re: multi-page form [message #174717 is a reply to message #174711] |
Wed, 29 June 2011 13:10 |
Jeff North
Messages: 58
Registered: November 2010
Karma: 0
|
Member |
|
|
On Wed, 29 Jun 2011 07:59:12 -0400, in comp.lang.php Jerry Stuckle
<jstucklex(at)attglobal(dot)net>
<iuf42j$m2e$1(at)dont-email(dot)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(at)attglobal(dot)net>
> | > <iudr6o$263$1(at)dont-email(dot)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(at)attglobal(dot)net>
> | >> |> <iudmb4$168$1(at)dont-email(dot)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.
|
|
|
|
| Re: multi-page form [message #174719 is a reply to message #174715] |
Wed, 29 June 2011 15:08 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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(at)attglobal(dot)net
==================
|
|
|
|
| Re: multi-page form [message #174720 is a reply to message #174717] |
Wed, 29 June 2011 15:09 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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(at)attglobal(dot)net>
> <iuf42j$m2e$1(at)dont-email(dot)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(at)attglobal(dot)net>
>> |> <iudr6o$263$1(at)dont-email(dot)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(at)attglobal(dot)net>
>> |>> |> <iudmb4$168$1(at)dont-email(dot)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(at)attglobal(dot)net
==================
|
|
|
|
| Re: multi-page form [message #174722 is a reply to message #174719] |
Wed, 29 June 2011 16:27 |
me
Messages: 192
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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
|
|
|
|
| Re: multi-page form [message #174723 is a reply to message #174711] |
Wed, 29 June 2011 16:56 |
Michael Fesser
Messages: 215
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
.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
|
|
|
|
| Re: multi-page form [message #174724 is a reply to message #174710] |
Wed, 29 June 2011 17:00 |
Michael Fesser
Messages: 215
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
.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
|
|
|
|
| Re: multi-page form [message #174725 is a reply to message #174677] |
Wed, 29 June 2011 17:05 |
Michael Fesser
Messages: 215
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
.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
|
|
|
|
| Re: multi-page form [message #174726 is a reply to message #174725] |
Wed, 29 June 2011 17:44 |
William Gill
Messages: 31
Registered: March 2011
Karma: 0
|
Member |
|
|
On 6/29/2011 1:05 PM, Michael Fesser wrote:
> .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.
My client wants the user to fill out the application form. If I let the
user screw up, that's my problem.
> 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.
That goes w/o saying.
My concern is not when a user does what I want and expect, but when they
don't.
>> 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
May need to use different events, and realize nothing is 100%, but this
is a safety net.
As far as JS being disabled (mentioned regularly throughout this
thread), the user has two choices. 1) Print amd mail the pdf, or 2)
enable JS to do things "on line."
|
|
|
|
| Re: multi-page form [message #174727 is a reply to message #174723] |
Wed, 29 June 2011 19:32 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
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(at)attglobal(dot)net
==================
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]