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.

Tuesday, November 04, 2008

Performance Reviews should be banished.

There's an interesting article at InfoQ stating that Performance Reviews should be banished. I just finished my own self-review last week, which is even more painful than a standard review. Rather than just having my boss tell me how he thinks I'm doing, which is a monthly conversation anyway, I get to hear the summation of the year in review. It shouldn't take as long as it does. I also get to rate myself in all of the categories and defend why I think I rated myself awesome.

I mean really, what person will rate themselves and not say I did awesome. Even if I know there are bad things the result will still be "awesome, considering the situations". I will always work hard, and put in hours at home learning new things and trying out new ideas. I will always put in time trying to better myself, I will always do my best to get all of my work done as well as stop to help everyone that I can as often as I can. That's awesome.

Maybe my biased opinion needs some perspective. Maybe this review offers the opportunity to hear an opinion that may not be just "awesome", but if it is, that would be awesome.

Monday, November 03, 2008

Turning Agile to 11

There's some very interesting topics covered in this 31 minute presentation on Turning Agile up to 11. It was a presentation that got me thinking about some of the things that we are not doing on our projects currently, and how some of these additional techniques could be helpful.

I am guessing that most Agile groups are not even working at 10, I know mine is not. However, you should always strive for these kinds of improvements in your process.