Mailing-List: contact tomcat-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: tomcat-user@jakarta.apache.org
Reply-To: <brett@knightsofthenet.com>
From: "Brett Knights" <brett@knightsofthenet.com>
To: <tomcat-user@jakarta.apache.org>
Subject: Re: How to disable Backspace Button in the Keyboard
Date: Fri, 1 Jun 2001 06:59:22 -0700
Message-ID: <000201c0eaa3$10bc0420$0201a8c0@knightsAPC.knightsofthenet.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
In-Reply-To: <991401360.1162.ezmlm@jakarta.apache.org>
Importance: Normal

If IE behaves the same way that would be an excellent solution.

Regarding state though what I do is have a "flow" number that sent with each form page as a hidden field.
Each time the user submits a form the value is incremented before the next page is sent back.
I only process the form if the returned value is less than the "last processed" value (held in the session).

For most apps if the form is double submitted I just re-display the result page with the current state of the app.

This has worked very well for me.

This was based on an article in either Dr Dobbs or Web Techniques (I believe the former) regarding transactionally aware web apps.
Highly recommended reading if you are working on that sort of app. (Sorry I can't supply the issue information - those copies are in
a box somewhere in the garage)

HTH

> A cool solution for this that actually works is that you use
> a Controller
> and a Renderer servlet, the Controller taking all the
> parameters, and then
> response.sendRedirect the user to the Renderer, storing
> whatever state is
> neccessary in the user's session.
>
> The nice thing is that you "skip" the Controller in the
> browser's history,
> and (at least on Netscape), the history actually realizes
> that multiple
> loadings of the same page is just "one event", and you end up
> with only
> one history entry for your whole application. If you press back after
> clicking 589 times in your application, you immediately exits
> back out of
> your application to the page you were before those 589 clicks.
>
> But of course, you have to put the "state" in the session too. A state
> variable as in a state-machine (state diagram, whatever, you know the
> circles with arrows pointing back and forth, each circle
> having a letter
> or digit in it. ;), telling the system where you are, so that the user
> can't f... up the routes in your application.