Error during navigation before response fully rendered - cri

[jeneric]

We've got our application almost ready to go (seam 1.1.6, myfaces) but we need to address a critical error that occurs during page navigation. If a user accidentally clicks to navigate prior to a previous navigation's response being rendered - the system crashes and returns the user to the default - no conversation view-id.

Here is an example of the navigation flow...

 Step 1 Step 2
 click link OK click link Not OK
Default ViewId --> ViewId2 --> ViewId3
 / \
 | Step 3
 | click link Not Ok
 | --> ViewId4

While ViewId3 is being rendered
 (step2 is being processed) the
 user clicks another link to go
 to ViewId4. Neither ViewId is
 rendered correctly - the system
 redirects the user back to the
 default ViewId.

Is there a common approach to solving this scenario - basically we want to block the user from performing any navigation prior to the response getting fully rendered?
We were hoping to avoid having to put javascript on all the submit buttons/links for disabling the forms.

[jeneric]

bump

[jeneric]

I can't believe that we're the only ones with this problem. Just try clicking away on some different s:links before the first click's response is rendered.
I don't believe this is a JSF problem, it's appears to be more of a seam problem (losing a handle to the conversation).
Any help from the seam guys (or anyone else) would be greatly appreciated.

Thanks

[dajevtic]

First of all be asured that you're not the only one who encountered this problem.
In Trinidad e.g. they tried to solve this issue, by adding a block attribute to their commandLink and commandButton tags.

What we did (in order to prevent the user from double clicking, etc.) we added ONE javascript to the form tag's onsubmit attribute which adds a layer on top of the page.

If you use ajax, then you also need to add a timeout that checks the state of the document (completed, etc.) and if it is completed than you need to render the layer invisible again.

[dajevtic]

but also let me add, that we haven't used this script in a long time, because the problems you describe seem to have already been solved in newer versions of JSF and Seam.

[gavin.king]

Seam 1.2 introduced a new concurrency model that probably solves this.