[
https://issues.apache.org/jira/browse/MYFACES-3804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13813459#comment-13813459
]
Leonardo Uribe commented on MYFACES-3804:
-----------------------------------------
The code contains tab characters and does not follow the code conventions
enforced by checkstyle. How are you writing the code? are you using maven? svn?
I receive checkstyle errors when I apply the code. Are you compiling the code
using maven?. The patch must not contain tab characters, and the brackets must
be properly set.
About the patch, I think reuse add() method of SerializedViewCollection is not
the right thing to do. Instead, the best way is create a method called for
example update(...) and call it from outside. Also the condition in
restoreSerializedView looks suspicious, because with that you are bypassing all
the logic related to generate the next token. Suppose you have an ajax request
and then there is a navigation, not caused by a redirect but normal navigation.
In that theorical case, the key will not be generated again.
If you want to discuss this issue please send a mail to dev likes with topic
starting with [core] .... as topic.
> 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: ajaxviewkey.patch, ajaxviewkeytest.patch,
> ajaxviewkeytest2.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)
