Customers are always coming up with different requirements like this; often we have to come up with some weird hack to make it work. A friend of mine, Chris Vishwanathan authored an article last year with a different scenario. This one where the customer wanted to save any data entered into a portlet form when ever the user navigated away and then back to the page. Similar scenario, just a different requirement on the portlet. Check out Persisting portlet forms data in WebSphere Portal V5.1 for more info on that one.
It have been awhile since I have had to figure something like this out, so I thought I might spend a little brain power to think about a solution. In this case the results I was seeking were small enough that I could spend a little time on researching the problem. Obviously my day job prevents me from activitvely solving every question I receive. : ) My first step was to see what happens in the portal today that we could leverage. I cooked up a couple of test portlets to see what happens. I got the following scenarios.
- The doView() of every portlet seems to be called every time the page refreshes. This is true even when another portlet is being used, or you are refreshing the entire page by clicking on the tab for that page. To me this sets up the idea that we can reset a portlet view when we need to.
- processAction() is being called only if you are interacting with a specific portlet. This tells me that I can track when a user is interacting with this specific portlet or another portlet on the page.
I thought we could use this relationship to try and reset portlets when necessary. One caveat here is that I was told there would only be one portlet on the page. With multiple portlets, depending upon what function they performed some of this may need to be reconsidered. The key here for me would be that any action within the portlet needs to go through the processAction() method and a parameter could be set to let the doView() know that things were ok. If the parameter was not set that it would trigger the doView() to know that this was an actual refresh, or that the user was working somewhere else within the portal.
The resetting of the page itself has to be portlet specific. In this case I don't know whether this is a form, or some type of in portlet navigation that the user is performing, but I think those specific can be worked out once a design approach is designed upon.
Anyway, these are just some thoughts, I would love to her how others have approached similar problems or if these thoughts are useful to others. I'm better other projects have similar requirements that are just slight different from what I outlined here. What tricks did you come up with in solving these challanges?