You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by "Dora Rajappan (JIRA)" <de...@myfaces.apache.org> on 2013/11/01 13:35:20 UTC

[jira] [Updated] (MYFACES-3804) Use the same key in server side state saving for ajax requests

     [ https://issues.apache.org/jira/browse/MYFACES-3804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dora Rajappan updated MYFACES-3804:
-----------------------------------

    Status: Patch Available  (was: Open)

> 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
>
> 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)

Re: [jira] [Updated] (MYFACES-3804) Use the same key in server side state saving for ajax requests

Posted by Flavio Magacho <fl...@m4u.com.br>.
unsubscribe



2013/11/1 Dora Rajappan (JIRA) <de...@myfaces.apache.org>

>
>      [
> https://issues.apache.org/jira/browse/MYFACES-3804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel]
>
> Dora Rajappan updated MYFACES-3804:
> -----------------------------------
>
>     Status: Patch Available  (was: Open)
>
> > 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
> >
> > 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)
>



-- 
*Flavio Magacho*
[image: cid:image001.gif@01C940F0.871FB2A0] Gerênte de Desenvolvimento
                Diretoria de Tecnologia da Informação
+55 (21) 2546-4050 ▪ Ramal: 4082
+55 (21) 98889-1572
*O conteúdo desta mensagem é confidencial e pode ser privilegiado. **É
vedada a sua cópia ou divulgação.*
*The contents of this message are confidential and may be privileged.
Copying or disclosing is prohibited.*