The situation is that AsyncCallback failure is NOT firing and when we have code split points and there are ONLY User interface changes i.e. ux changes, and a user has navigated on all pages of the previous version of the app, even with the cache control header (with a servlet filter), the failure does not fire i.e. the old UI works fine with the services and cannot detect the new UI client on the server unless the user explicitly refreshes UI does not refresh.
Any thoughts... examples, best practice. I sincerely hope I am missing something as this is very tricky trapping all the what if scenarios when there is a new app.
Cheers and Thanks....
On Wednesday, January 11, 2012 8:56:59 AM UTC-5, Kyle Baley wrote:
We've gone Thomas's original suggest route of informing the user. But in our original pass at this, we threw up a dialog with an OK button on it. It said something to the effect of "There's a new version. Please log in again". Clicking OK is intended to log the user out and forcibly refresh the page.--What we're finding is that for the code-splitting case, the dialog does indeed come up but the whole page becomes unresponsive afterward. That is, you can't click the OK button. I've verified that this happens regardless of whether we put a dialog up or not. Nothing on the page is clickable at all. Wondering if this is what others see as well and if so, if there's a way around it.
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/wJETtqpLYysJ.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to google-web-toolkit+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
No comments:
Post a Comment