ASP.NET Approach To Back Button Problem
Microsoft being both a web framework vendor and a browser vendor, has built in an interesting feature into ASP.NET web framework called SmartNavigation. When Internet Explorer 5.5 or higher receives a response from an ASP.NET application and SmartNavigation is turned on, the following actions are performed:
- The flash caused by navigation is eliminated
- The scroll position is persisted when moving from page to page
- Element focus is persisted between navigations
- Only the last page state in the browser's history is retained
According to the Microsoft® .NET Framework Class Library documentation, smart navigation is best used only with ASP.NET pages that require frequent postbacks but have visual content that does not change dramatically on return.
There are numerous reports about smart navigation being restrictive and downright buggy. Microsoft acknowledges that "smart navigation is a feature that must be tested in every particular scenario to be sure the proper behavior is exhibited."
Nevertheless, the last bullet in the above feature list is very interesting because it shows a different approach to a dreaded problem of web applications known as "Back button issue".
Controlling browser session history: ASP.NET way
Smart navigation feature of ASP.NET framework prevents each postback from being saved in the browser history. Normally, every postback to an ASP.NET page causes an entry to be created in the browser's history. This defeats the purpose of the browser's back button because instead of going back to the previous page, users are taken to the previous state of the current page. Smart navigation prevents this from happening by saving only the latest state of the current page in the browser's history.
This approach solves issues with Back button because it eliminates the very possibility to navigate to a stale page. At the same time, it allows to manage application state on client, offloading this task from the server session object. This is a brilliant idea, at least for pre-Ajax era.
Controlling browser session history: Struts way
Struts framework cannot target Internet Explorer 5.5 or higher as the only platform, therefore a hack like SmartNavigation cannot be considered a viable solution. But let this not get you down, there are other solutions that work equally well or better, and do not depend on particular browser vendor. Among these solutions are:
- Struts web islands – an logical improvement to a well-known Redirect-After-Post pattern. Works in most browsers including ancient ones, does not require Javascript.
- Struts web components – a component-based solution, does not require Javascript but uses it if available. Without Javascript incurs full page reload similar to StrutsWebIslands approach. With Javascript enabled a portion of a page is updated in-place, which is faster and does not cause growth of browser session history.