Interesting that you mention about the BACK button. We have a problem on our
site with the back/forward button. When I set the header of every page to
not cache so that it always goes to the server, if the back button is used,
the page has expired! If I allow caching, then they sometimes get a browser
cahced page and it doesn't reflect the server state. So how the heck do we
avoid this? I have tried to tell my fellow peers that we should have text on
every page of a transaction that says DO NOT USE THE BACK/FORWARD buttons of
your browser. But they don't agree with that, so now we have a QA engineer
that is always pissed off that we developers can't seem to fix the
back/forward problem. I recall that there is a way in javascript to "stop"
the previous page from being stored..so the back button doesn't actually go
to it? Is this possible? Something like document.history(-1).value = ""; or
something? Is that a good way to prevent the back button from actually going
to a previous page?
If not, what ways has anyone come up with to prevent the back button from
screwing up the state of the session, pages, etc. My worse one is if they
hit the BACK button then hit SUBMIT, or if they hit the back button, the
forward!
HELP! ;)
>
> Hi!
> Talking about web apps and state-machine I have some questions:
>
> * What are we actually talking about?
> In my understanding, we're talking about web applications that
> have a model
> stored in the session which "is" a finite state machine, and
> Always in my understanding, and this is how the things should work:
> - the View sends an Action to the Model
> - the Model decides, based on its actual state and the Action
> its next state
> - the next View page displays the informations about the actual
> state of the
> Model
>
> * Doesn't the Back Button causes this architecture to fail?
> I think the only way you have to let it work is to store in the
> URL (which means
> in the Actions) all of the parameters that are necessary to
> reconstruct the
> state of the Model every time a page is submitted... but it seems
> to me not a
> very good state machine...
>
> * If I have misunderstood something, may somebody please correct me?
> * And anyway, what are the you people out there doing with your
> web apps, when
> you have such a complex state that is not "storable" in the URL
> to prevent the
> errors caused by the back button?
>
> Thanks in advance, I hope to have been clear enough :-) ...
>
>
> BRAIN Development GmbH
> Andrea Vicentini
> System Engineer e-Business
>
> Phone: +49 (7151) / 602-332
> Fax: +49 (7151) / 602-372
> Internet: http://www.brainag.com
> e-mail: [EMAIL PROTECTED]
> [EMAIL PROTECTED]
>
> ==================================================================
> =========
> To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff
> JSP-INTEREST".
> Some relevant FAQs on JSP/Servlets can be found at:
>
> http://java.sun.com/products/jsp/faq.html
> http://www.esperanto.org.nz/jsp/jspfaq.html
> http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
> http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
>
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
Some relevant FAQs on JSP/Servlets can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
