[
https://issues.apache.org/jira/browse/MYFACES-3804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13860889#comment-13860889
]
Leonardo Uribe commented on MYFACES-3804:
-----------------------------------------
I have checked the patch provided, but I didn't see anything new. If you
provide a solution and you need to do some improvements, please include the
complete solution in a single patch (including tests and everything). The
common convention is put the issue number on the patch and another number to
indicate the iteration.
I did some cleanup on the server side state saving algorithm and on the way I
have studied this problem and the one in MYFACES-3806 and I have realized both
are related somehow, so I fixed both in a single patch. I have attached it, so
you can see the difference. The fundamental idea that was not in the first
patches was change the code but keep
ServerSideStateCacheImpl.getNextViewSequence(...) and nextViewSequence(...)
logic in place. The trick was very simple: when the view is restored, if there
is an ajax request, save the viewId and the viewKey of the current request.
Then when a view sequence is needed, check if the current request is still on
the same view and if that so reuse the current viewKey.
> Use the same key in server side state saving for ajax requests
> --------------------------------------------------------------
>
> Key: MYFACES-3804
> URL: https://issues.apache.org/jira/browse/MYFACES-3804
> Project: MyFaces Core
> Issue Type: Improvement
> Components: JSR-344
> Reporter: Leonardo Uribe
> Fix For: 2.2.0
>
> Attachments: MYFACES-3804-4.patch, ajaxviewkeytest.patch,
> ajaxviewkeytest2.patch, ajaxviewsamekey.patch, ajaxviewsamekey2.patch,
> ajaxviewsamekey3.patch
>
>
> The current code for server side state saving creates one key per request to
> store the view state. This is ok, but it is not necessary for ajax requests.
> The reason why is not necessary is because you can never go back to a page
> when using ajax. If you are on page A and the current request is an ajax
> request and it returns to the same page and the view is the same that the one
> that has been restored, the key or the token sent does not need to change,
> what changes is the internal state of the view. From the client side the page
> is the same. We can take advantage of this fact and just update the state
> stored in SerializedViewCollection for the view.
> The challenge here is detect when this strategy is applicable. For example,
> what happen if there is an ajax redirect? It looks is a good idea for
> implement in 2.2, because it avoids to store unnecessary information into
> session and optimize the use of each view slot.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
