p2p.wrox.com Forums

Need to download code?

View our list of code downloads.


  Return to Index  

beginning_php thread: problems with the back button


Message #1 by "Trey Carroll" <treycarroll@y...> on Thu, 20 Feb 2003 20:15:09
I keep running into issues with the back button.  I frequently write 
scripts that work well 'forwards' but cause problems when the user clicks 
the back button.  An example would be a script that changes user 
information in the db.  It works great forwards, but when they back over 
it, the session variables have been destroyed and it re-executes with 
blanks for all fields, wiping out the valid information.

I have used a piece of javascript to solve this problem before:

echo "<script language='JavaScript'>window.history.forward(1);</script>\n";

but this doesn't always work for some reason.

I notice that the webmail client, NeoMail, that mylinuxisp uses has the 
same issue: hitting the back button remails anything that you have sent.

Anybody have a strategy to deal with these situation?
Message #2 by "David Scott-Bigsby" <DScott-Bigsby@P...> on Thu, 20 Feb 2003 12:49:40 -0800
Trey,

I dealt with this in a script I'm just now testing.

The essential issue is that you only want to execute subsets of code as 
the user moves through your process on a path of your choosing. Easy to 
implement in many environment, but not the web -- users can go back (and 
worse, refresh).

I addressed this by mapping out the states my application can be in for 
a particular user, the valid transitions between states (e.g., 1->2 and 
1->3 are okay, 1->6 is not), and what happens when the user attempts a 
transition (e.g., if 3->4, validate input, if invalid, return to 3, else 
to to 6). The user's current state is stored in the session table in my 
database.

In the case of the e-mail program you described, clicking on the "send" 
button could move the user from the "edit" state to the "done" state. 
When the user goes back a page, your script could enforce a rule that 
done->edit is not allowed, and kick them somewhere else.

I've found states -- more formally, state charts -- a huge help in 
programming in several languages, and for defining user interface 
behaviour. They're covered by UML, and there's lots on the web about 
them.

dsb

***************************************       
David Scott-Bigsby
Product Manager, Web Site and PEDN

PureEdge Solutions
The Leader in Secure XML e-Forms

v:250-708-8145  f:250-708-8010
1-888-517-2675   www.PureEdge.com
***************************************


> -----Original Message-----
> From: Trey Carroll [mailto:treycarroll@y...]
> Sent: Thursday, February 20, 2003 12:15 PM
> To: beginning php
> Subject: [beginning_php] problems with the back button
>
>
> I keep running into issues with the back button.  I frequently write
> scripts that work well 'forwards' but cause problems when the
> user clicks
> the back button.  An example would be a script that changes user
> information in the db.  It works great forwards, but when
> they back over
> it, the session variables have been destroyed and it re-executes with
> blanks for all fields, wiping out the valid information.
>
> I have used a piece of javascript to solve this problem before:
>
> echo "<script
> language=3D'JavaScript'>window.history.forward(1);</script>\n";
>
> but this doesn't always work for some reason.
>
> I notice that the webmail client, NeoMail, that mylinuxisp
> uses has the
> same issue: hitting the back button remails anything that you
> have sent.
>
> Anybody have a strategy to deal with these situation?
>
Message #3 by "Nikolai Devereaux" <yomama@u...> on Thu, 20 Feb 2003 13:21:13 -0800
> I keep running into issues with the back button.  I frequently write
> scripts that work well 'forwards' but cause problems when the user clicks
> the back button.  An example would be a script that changes user
> information in the db.  It works great forwards, but when they back over
> it, the session variables have been destroyed and it re-executes with
> blanks for all fields, wiping out the valid information.
>
>    <snip>
>
> Anybody have a strategy to deal with these situation?

Here's what I'd do:

Generate a unique ID for each form generated during a user's session.  When
the user submits a form, check to see if that form ID has already been
submitted and processed.  If not, process the form and mark that ID as used.
If it has, then the user has already submitted that particular form, and is
probably viewing the page by refreshing or going back through the history.

This shouldn't take up too many resources.  As part of the session destroy
action, you can safely delete all of the form ID tracking.  The same IDs can
be generated for multiple users, since it's the session_id/form_id combo that
needs to be unique.

Does this makes sense?  If not, I can go into more detail.


Take care,

Nik

Message #4 by "Nikolai Devereaux" <yomama@u...> on Thu, 20 Feb 2003 13:52:53 -0800
> I've found states -- more formally, state charts -- a huge help in
> programming in several languages, and for defining user interface
> behaviour. They're covered by UML, and there's lots on the web about them.

David,

That's a _much_ better solution than mine.  You're my hero!

I've mentioned in the past storing the last page a user selected to avoid the
refreshing problem, I never really thought to extend that into states.


Gotta love your FSMs. =)

Nik

Message #5 by "Nikolai Devereaux" <yomama@u...> on Thu, 20 Feb 2003 14:06:06 -0800
  (RE:  Tracking form validity using a page-based
        state machine with directional transitions.)

I should mention one thing, though -- the larger your site is, the more states
you'll have to keep track of.  It shouldn't have to be a big deal, though --
one can simply say that if an edge (transition from state to state) doesn't
exist, then the transition is invalid.

Further considerations have brought me to think that my solution does have
it's benefits -- it's fast, doesn't require maintenance of a potentially large
state machine (do you keep a state for every linked page from a particular
page?  What about a link menu on the left hand margin, or top banner, etc...?)

Keeping track of form_id values does have the advantage that you only have to
check these values when a form is submitted.

A user can safely submit the same form twice (if you want them to have that
capability), as long as they *submit* the new form and don't use the
forward/back/refresh buttons to do so.


There's also the issue that a user could submit a form, realize they made some
mistake, then hit back, change something, and resubmit the form.  In a really
robust system, this kind of [screwy] user-end error recovery should be
accomodated.  If you discover that going back to the form is an invalid state
and bounce them somewhere else, then this will confuse and possibly scare them
into thinking they've made some unfixable mistake.


In the long run, then, I suppose the best thing to do is to try to figure out
how to code up both solutions, think long about the pros and cons of each (or
perhaps some merging of the two), and do what's best for your site.


Take care,

nik

Message #6 by "Trey Carroll" <treycarroll@y...> on Thu, 20 Feb 2003 23:05:45
Here's what I'd do:

Generate a unique ID for each form generated during a user's session.  When
the user submits a form, check to see if that form ID has already been
submitted and processed.  If not, process the form and mark that ID as 
used.
If it has, then the user has already submitted that particular form, and is
probably viewing the page by refreshing or going back through the history.

This shouldn't take up too many resources.  As part of the session destroy
action, you can safely delete all of the form ID tracking.  The same IDs 
can
be generated for multiple users, since it's the session_id/form_id combo 
that
needs to be unique.

Does this makes sense?  If not, I can go into more detail.

Take care,

Nik

Message #7 by "Trey Carroll" <treycarroll@y...> on Thu, 20 Feb 2003 23:18:37
I used a simplified version of this idea and it works wonderfully.  I 
don't have to keep track of quite as much information.  I simply give the 
form an id in the initial form and put that id into a session variable.  
When the form is processed, I overwrite the id with the 
string "PROCESSED".   The code that does the actually db UPDATES is inside 
an 

if ($SESSION['form_id'] != 'PROCESSED')
   {
    ...
    DB UPDATE CODE
    ...
   }

Now, even if they hit back or refresh, once is all that the form gets 
processed.

The session variable, $SESSION['form_id'], is not unregistered and the 
session is not destroyed, since this is a 'detour' from a main page that 
is using other session vars.

Thanks so much for this invalable help- this issue has been giving me fits.

Thanks also to David.  I can see how maintaining state will come in handy 
for more complex situations in the future.

Trey


Message #8 by "David Scott-Bigsby" <DScott-Bigsby@P...> on Fri, 21 Feb 2003 09:54:42 -0800
>   (RE:  Tracking form validity using a page-based
>         state machine with directional transitions.)
>
> I should mention one thing, though -- the larger your site
> is, the more states you'll have to keep track of.

True -- the site I run has several multi-step processes, but most pages 
are HTML. Or, more significantly, are not a stage in a process, so I 
don't track users through them. (Except through our all-seeing-eye web 
log analysis software, of course.)

Of course, many sites which appear complex (e.g., a web forum of forums) 
may break down to a half-dozen states under analysis. Even if you don't 
implement a "state machine", such analysis can point to a more modular 
and consistent design.

dsb

***************************************       
David Scott-Bigsby
Product Manager, Web Site and PEDN

PureEdge Solutions
The Leader in Secure XML e-Forms

v:250-708-8145  f:250-708-8010
1-888-517-2675   www.PureEdge.com
***************************************

Message #9 by "Nikolai Devereaux" <yomama@u...> on Fri, 21 Feb 2003 11:36:07 -0800
I agree completely.  For a form process that spans multiple pages, you'll
likely need some sort of state machine if those forms must be completed in a
specific order.

Examples come to mind:

  Auto insurance quote applications
  Registering for an account on hotmail
  etc..

Message #10 by "Mark Ryan" <Mark_W_Ryan1@h...> on Fri, 21 Feb 2003 15:13:33 -0500
We use a modal window.  " window.showModalDialog()"
 That way a user cannot stray away from the correct sequence of events. The
down side is that values have to be passed on the url.


----- Original Message -----
From: "Nikolai Devereaux" <yomama@u...>
To: "beginning php" <beginning_php@p...>
Sent: Friday, February 21, 2003 2:36 PM
Subject: [beginning_php] RE: problems with the back button


>
> I agree completely.  For a form process that spans multiple pages, you'll
> likely need some sort of state machine if those forms must be completed in
a
> specific order.
>
> Examples come to mind:
>
>   Auto insurance quote applications
>   Registering for an account on hotmail
>   etc..
>
>
>

  Return to Index