[jira] [Commented] (EXTCDI-218) defer final deletion of @ViewAccessScoped beans

["Mark Struberg (JIRA)" <de...@myfaces.apache.org>]

    [ https://issues.apache.org/jira/browse/EXTCDI-218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13093496#comment-13093496 ] 

Mark Struberg commented on EXTCDI-218:
--------------------------------------

A few ways to solve this:

1.) use the ClientSideWindowHandler: This is the only known fully functional solution for windowId handling. The problem is that it leads to slight flickering for the users (because an 'intermediate page' has to be rendered which detects any fresh browser window and loads the real destination via JavaScript)

2.) Instead of terminating @ViewAccessScoped immediately when a new viewId gets detected we only 'defer' them and clean them up on the following request. If he dropWindowId.js script detects a fresh browser window, it can pass the originalWindowId=123 as parameter so we can 'rollback' the deferring. I know that this is not an optimal solution but it would probably be the easiest way to fix the behaviour.

3.) Implement a history for @ViewAccessScoped beans. This is something which we thought about since a long time already. This would allow recovering on browser back buttons.


> defer final deletion of @ViewAccessScoped beans
> -----------------------------------------------
>
>                 Key: EXTCDI-218
>                 URL: https://issues.apache.org/jira/browse/EXTCDI-218
>             Project: MyFaces CODI
>          Issue Type: New Feature
>          Components: JEE-JSF12-Module, JEE-JSF20-Module
>    Affects Versions: 1.0.1
>            Reporter: Mark Struberg
>            Assignee: Mark Struberg
>
> I have a tricky problem in production with @ViewAccessScoped beans in conjunction with the lazy windowId dropping script
> http://wiki.apache.org/myfaces/Drafts/WindowId
> The problem arises if the user is on the browsers tabA (windowId=123) which has a @ViewAccessScoped bean and opens a link from this window in a new tabB.
> In this case a request with the old windowId=123 (*) will be sent to the server and the response will be rendered to tabB. When the dropWindowId script detects that tabB is a fresh browser tab, it will issue a new request and drops the windowId to get a new one (windowId=124 now for tabB)
> The problem is that in step (*) we get a request with the _old_ windowId onto a new view, thus we drop the @ViewAccessScoped bean used in tabA.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira