[
https://issues.apache.org/jira/browse/MYFACES-3804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13813896#comment-13813896
]
Dora Rajappan commented on MYFACES-3804:
----------------------------------------
Thanks for your reply. Let this discussion go in here for ease.
You are talking about the tab characters in testcase. I will submit new patch
for that. I had not saved the format.
I am not using checkstyle for now. I will configure it.
I use maven for build/test, svn yes but outside of eclipse.
add() can change to update. I will make that change.
In normal navigation you have a key and next key for the new view built which
passed to add of SerialisedViewCollection.
But in the case of ajax and normal navigation same thing happens new view built
is passed to add of SerialisedViewCollection. What happens now is in invoke
application executor the action is processed and navigation handled and next
view is created and this view is in same execute cycle and this overwrites the
ajax view and gets rendered with ajax view id in the page.
Not altering this behaviour above ajaxwithsameviewkey fix is extended to normal
navigation by means of add instead of update of SerialisedViewCollection.
Regarding the condition in restoreSerializedView looks suspicious, this bypass
is only for ajax request and hence its affects only ajax requests. But I have
changed code to put the state id in SERVER_STATE_ID and not in SEQUENCE_PARAM.
Is this fine tuning required for ajax since redirect and navigation are avoided
:)
> 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
> Attachments: 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#6144)
