<img height="1" width="1" style="display:none;" alt="" src="https://px.ads.linkedin.com/collect/?pid=299788&amp;fmt=gif">

Back Button Considerations for Portlets

Software Development, Portal, Software Solutions

In a portal developer's perfect world, or any web developer's for that matter, a browser wouldn't have a back button.  But we know this is not the world we live in and, in fact, users LOVE their back button.  Fortunately for portal developers, we don't have to fundamentally change the way our applications work.  Our applications work properly already due to the action/render request lifecycle.  All we need to do is adhere to a few simple concepts and the back button for the most part will take care of itself.


There is a common problem in web applications when users submit form data resulting in a re-submit if the page is refreshed.  This same problem can also be caused by the use of the back button on subsequent requests.  These can show problems such as displaying a dialog warning the user on re-submittal along with a 'Page Expired' message if the back button is used.
How does this happen?  It occurs when a web application processes the results during the Post method and then returns the results to the user during the same lifecycle (i.e. during a doPost in a servlet).
Here are the steps that occur in a problematic Post request:

  • User Post submits form
  • Server processes form
  • Server returns results in the response (typically forwarded to a JSP)
  • User does a browser refresh - the Post submit is made again (OUCH)

portlet development


The PRG web development pattern allows us to avoid the form re-submittal problem and create a 'safe interaction' that is safe to navigate, is repeatable, cacheable, and bookmarkable(1).
Here are the steps during PRG:

  • User Post submits form
  • Server processes form
  • Server redirects user's browser to a URL for view with all proper parameters
  • User's browser does a GET request using the new URL
  • User does a browser refresh (or later clicks back button) - only the GET request is made

portlet development


Portal developers may ask themselves, "How do I get in on this?"  The answer is we get it absolutely free!  There are only a few steps you need to take.

  • Make sure the portal is doing Post/Redirect/Get - Though portals will follow this two-phase lifecycle, you must check to see if your portal is actually doing the redirect to effectively use the Post/Redirect/Get pattern. Some portals are set by default to return results to you after Post, which doesn't allow us to enjoy the benefit of PRG.
  • Avoid use of session variables - particularly if changes to session variables will cause view results to change. This can confuse users when they see the same data repeat as the back button is pressed or worse, inconsistent results. If the portal is properly using PRG and session variables are not used for query results, the view results should be back to what they were previously. Changes would only occur if the underlying data had changed.
  • Use Render Parameters during action phase - use the actionResponse#setRenderParameter(...) method to ensure the generated URL used for redirection (and subsequent Get render requests) contains all the parameters needed to display the correct results to the user during the render phase. This guarantees parameters will be there for refreshes and back button navigation.
  • Caution using action scoped request attributes (session-backed by portal) - this vendor specific option can have varying results with the back button depending on how it's configured. Using the 'numberOfCachedScopes' setting in portlet.xml allows a number of cached object results in the session to work with a corresponding number of back button presses. So, if you pressed the button five times, your Get request would result in the retrieval of the proper action scoped request object from the render request that was originally placed there five steps back. The portal does this under the covers for you, but you can easily see that this would make bookmarking that URL impossible, as those objects would not be available.
  • Only make state changes during action phase, not render phase - this is a general must-use practice in order to receive consistent results


If the above guidelines are adhered to, back button presses should not cause you too much worry.  If you have existing portlet applications that clients are demanding to be back button friendly, it isn't the end of the world.  You can certainly see the steps you'd have to go through to achieve this (changing session variables to render parameters, checking portal settings, etc).  Then it's just a matter of testing with that back button.  Good luck!
(1) http://www.subbu.org/blog/2006/06/is-the-portlet-programming-model-broken

TAGS: Software Development, Portal, Software Solutions

0 replies

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Subscribe to Our Newsletter

Recent Blog Posts