Rethinking the back buton

Rethinking the back button problem

There are a host of problems when dealing with web browsers that implement a corporate intranet application and not just browsing static content or simple applications like blogs. Here are some typical problems:

- Double clicking and submitting several times the same form.
- Using the back button once or several times and then the user resubmits the form with a warning from the browser.
- Using the back button and then clicking on a link. The link relied on information stored in the user session on the server which is no longer there.
- The refresh button or F5 problem.
- The several navigator windows problem. (Ctrl-n)

There are different ways of solving these problems some more elegant than others. For example a typical way of dealing with the back button is by expiring the page. This works but is not very user friendly. The user ends up either going back again or forward and gets lost quickly.

Another way is to eliminate the back and forward buttons altogether by putting the entire application in another window without the menu items and then providing “internal” back buttons. Well putting an application in another window is clunky; what do you do with the original window? Also the user can always use the backspace and F5 buttons.

A secure and surefire way of dealing with back, refresh, and double clicks is with a synchronizing token. Each form has a unique generated token from the server and only a submission with the same token is allowed. Once a token has been used it cannot be reused. This works real well, but the user is left with a page saying that operation has already been treated. Where does the user go now? It’s not elegant.

Most of these strategies revolve around suppressing the use of these buttons. But there is a possibly a better way! In several of my recent projects instead of restricting things I’ve actually embraced the use of these buttons. Yes it sounds frightening but in the end the users are happier because the browser behaves like the rest of the web and thus there are less user experience problems.

Here’s the basic strategy:

1. Stop double clicks on action buttons with a simple javascript
2. Let users repost if they want to, no token. This could even be a feature. Create 10 things really fast. Submit, back, submit, back, etc.
3. All other links (requests) should contain the entire context in the URL. If context is too big use class serialization and then compression and then post instead of get. This actually works.
4. Redirect on the client and not on the server after creation, modification, or deletion. This eliminates the refresh problem.
5. For things that you really don’t want to resubmit use a token. From a business perspective there might not be that many.

I can write howtos if anyone is interested. Just leave me a comment.

How to log a class with JBoss and log4j.xml

Here's an example of how to log just one class in JBoss.

First in the Java class you want to log com.mycompany.MyClass.java:

if(log.isDebugEnabled()){
log.debug(System.currentTimeMillis());
}


Then in the log4j.xml do not add a threshold parameter to the appenders. I think it overrides all other categories. Instead add a priority value in the root logger.

<appender name="CONSOLE" class="org.apache.log4j.ConsoleAppender">
<errorHandler class="org.jboss.logging.util.OnlyOnceErrorHandler"/>
<param name="Target" value="System.out"/>

<layout class="org.apache.log4j.PatternLayout">
<!-- The default pattern: Date Priority [Category] Message\n -->
<param name="ConversionPattern" value="%d{ABSOLUTE} %-5p [%c{1}] %m%n"/>
</layout>
</appender>

<category name="com.mycompany.MyClass">
<appender-ref ref="CONSOLE"/>
<priority value="DEBUG" />
</category>

<root>
<appender-ref ref="CONSOLE"/>
<appender-ref ref="FILE"/>
<priority value="INFO" />
</root>