In our solution we’re using task links in email notifications sent from process (to provide direct navigation to the task for users).
We’re taking task urls from pub.task.taskclient:getTask service (TaskInfo/taskUrl output parameter, which looks like: http://server:port/8A7ADD89-F38A-F973-1089-F02F0BFBEDBA.task.app.details.page?wmp11411.taskID=61507).
This url ussualy works fine, however we’ve noticed one problem with this - take a look at the scenario:
User is logged to MWS and opens task (from MyInbox in “left menu”) of type X, the task id A. The bean for this task’s view is initialized (I see in debug logs) and user can normally work with the task.
User receive’s email notification with url to task B (which is also of type X). User clicks on the link, and task view is opened in new tab of the same web browser (in the same session, since he was already working in MWS).
The bean of task’s view is not initialized - MWS treat this request as the request for point 1 and shows the data which is stored in managed bean for task A, not B (consequenses are obvious, data inconsistency, user confusion, etc).
There is no problem if user open both tasks in 2 tabs of web browser from My Inbox - then user can work with both tasks independently. Howewer if one task is opened from “task url” the problem exist.
All beans implementing tasks have the “expireWithPageFlow” property set to “true” (I’ve also tried to change it to “false” but it doesn’t solves the problem).
It would be nice if users don’t work with many tasks in one session of one browser in parralel ;-), however we can’t prohibit to click on link in notification email…
Do you have any idea, how to solve this problem? Maybe some alternative task url to getTask’s one?
After some more investigation it looks that if you open 2 tasks of the same type in one session (one browser, different tabs) - the problem also exist. Two beans are initialized, but requests from both tasks are handled by one instance of the bean (last initialized one - probably).
Please have a look at this draft document. It describes a pretty interesting technique (the last paragraph sums it up nicely)
Regards,
–mark PageInitialization.doc (220 KB)
Thanks for advise. However I think this technique does not solve the issue. The technique deals with controling data initialization / refreshing, when the bean is already initiated by MWS.
The problem here is that MWS doesn’t start new bean instance when user starts view in new tab in the web browser. To work properly with multiple tabs in parallel, MWS should keep bean instance per browser tab, I guess (since all tabs work with the same session). That’s because bean keeps view’s data and from user perspective views from different tabs are independed (have independent data and state).
It seems to be generic (not only MWS) jsf / web problem, since different browser tabs can’t be recognized on the server-side and requests from all tabs goes within the same session.
I’ve search some materials and I see that some web frameworks introduce additional conversion mechanizm (different than sessionId). I see that JSF 2.0 introduces “view scope” for the bean, that might be the answer.
How do you deal with “multiple web browser tabs” issues in your CAF applications?
About the only way to effectively deal with the same portlet dealing with two different sets of beans is to have two unique portlets. That probably means creating portlets on the fly which is what workspaces are designed for. I imagine that if we’re talking about tasks though, these are pre-built workspaces and not user-created workspaces. That means, you’d have to modify the task notification links to generate a new workspace on the fly, and prepopulate a task details portlet pointed to an instance of the task.