Thursday, November 13, 2008

PRG pattern alternative

I'm working on a websphere portal application and in it I have a lot of operations. Sometimes I post, and sometimes I use servlets. But I don't do any gets.

A while ago I introduced a problem to the application. Instead of just performing a normal search, I added a queue, and a get next feature. In order to keep code to a minimum I used the same portlet and just changed the action to let my portlet know which action it was supposed to handle. The end result is that both methods give me an account to show on the screen, the only difference was in how they retrieved that account.

Things have been working great, until the page only have reloaded and a user hit F5. Then instead of just forcing the page to reload with the information that it should have already loaded, it is doing another Get Next and the user is losing the current account.

Some research on this problem led me to the PRG (Post/Redirect/Get) pattern. Redirect after Post is a great article on this solution. However, it's not what I wanted to implement. I didn't want to modify my process that much. I like how my portlets are working without trying to get the redirect working (which I have read may be a problem).

Instead I needed a way to know if the page was performing a new action, or if it was resubmitting the old one.

I opted for telling my page what ID it should tell me when performing an action. Initially this value is set to 0. The first action runs and tells the page that it should next call with a 1. If the page does not call with a 1 then instead of performing a real action the page will instead refresh the information on the screen without performing an action. When F5 is pressed it resubmits all of the information that was submitted in the previous post.

There are 2 keys to this.
1. I have a hidden field in my form that holds the ID to send with the rest of the information for the post.

2. I use the session to keep that same ID active in the session.

Trying to think about all aspects of this, I also tried to think of problems with this solution.
1. If the session times out the user will need to log back in, but the portal already enforces that behavior.
2. If someone were to manually massage that value would there be a problem? Since I actually do nothing if the value is not what I'm expecting, then changing the data with a tool like firebug will only prevent the page from doing things, instead of allow it to do things. Since there is no way to massage the data that is submitted by pressing F5, there is nothing that should be a problem.

No comments: