The Artima Developer Community
Sponsored Link

Java Buzz Forum
Back Button Blues

0 replies on 1 page.

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 0 replies on 1 page
John Topley

Posts: 233
Nickname: johntopley
Registered: Jul, 2003

John Topley is embarking on a journey to become a J2EE master.
Back Button Blues Posted: Dec 20, 2003 5:52 AM
Reply to this message Reply

This post originated from an RSS feed registered with Java Buzz by John Topley.
Original Post: Back Button Blues
Feed Title: John Topley's Weblog
Feed URL: http://johntopley.com/posts.atom
Feed Description: John Topley's Weblog - some articles on Ruby on Rails development.
Latest Java Buzz Posts
Latest Java Buzz Posts by John Topley
Latest Posts From John Topley's Weblog

Advertisement

“You should never go back” they said, and they were right. They probably weren't thinking about the problems of web application development when they said it though.

I've been struggling with the issue of handling the browser Back button correctly in a Struts application that I'm working on. The user is presented with a series of pages that make up a workflow process. I'm using an ActionForm with HTTP session scope because this is ideal for building wizard-style page flows, as the HTML form retains its values across multiple pages.

The problem comes if the user doesn't enter a value for one of the fields. Using the Struts validation features I can raise an ActionError that prompts the user to enter a value for that field. If the user then submits to the next page but then clicks the Back button, the error message is still there, only this time the field still has the valid value that was just entered! In other words, the application is now in a logically inconsistent state.

I hate you!
Back button

I've tried everything I can think of to solve this problem. The error message appears because the browser is returning a cached version of the page. I can turn off caching but then when the Back button is clicked the user gets that nasty IE page about the page being expired and needing to be refreshed. So they click the Refresh button and then they get a message dialogue that says that the page contains a form which requires that they click the Retry button to re-submit it. This returns them to the form and the errors are gone, only the values they entered are too. Hardly a slick user experience.

The Struts mailing list is full of messages from developers having similar problems, but I've not been able to find a definitive solution. Some misguided souls even ask if it's possible to disable the browser's Back button to avoid the problem entirely. Hint: people use web browsers all the time and are used to being able to go back—don't break their expectations of how the application is going to behave by attempting to cripple their browser. Sites such as Amazon let users jump to any point within the payment workflow as they please and everything is as you expect it to be, but then again, they use their own custom CGI solution. Are there any Struts meisters reading this who have the answer?

All of these problems stem from the fact that we're now using the stateless HTTP protocol for trying to deliver stateful applications. The technology behind the Web was designed to deliver static content. The browser-based application has been heralded as the solution to the problem of having to roll out traditional monolithic desktop applications to a large number of users within an organisation, and indeed it does solve this problem. It's also a great way to turn that shiny new 3 GHz computer on your desk into a dumb terminal.

Is offering an impoverished user experience by virtue of using this technology for something it was never designed for, really the best we can come up with?

Read: Back Button Blues

Topic: Struts Waning Previous Topic   Next Topic Topic: xwork/webwork2 logo contest

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use