You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by "Adam Winer (JIRA)" <de...@myfaces.apache.org> on 2007/07/20 00:59:06 UTC
[jira] Resolved: (TRINIDAD-116) PPR + State Management: reuse
state tokens while PPRing to avoid flushing the cache
[ https://issues.apache.org/jira/browse/TRINIDAD-116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Adam Winer resolved TRINIDAD-116.
---------------------------------
Resolution: Fixed
Fix Version/s: 1.0.2-core
Implemented.
> PPR + State Management: reuse state tokens while PPRing to avoid flushing the cache
> ------------------------------------------------------------------------------------
>
> Key: TRINIDAD-116
> URL: https://issues.apache.org/jira/browse/TRINIDAD-116
> Project: MyFaces Trinidad
> Issue Type: Improvement
> Affects Versions: 1.0.1-core
> Reporter: Adam Winer
> Assignee: Adam Winer
> Fix For: 1.0.2-core
>
>
> Today, if you have the following series of requests:
> 1. Page A
> 2. PPR #1 on A
> 3. Page B
> 4. PPR #1 on B
> 5. PPR #2 on B
> You get the following state tokens in the page:
> Request Token
> 1. Page A 1
> 2. PPR #1 on A 2
> 3. Page B 3
> 4. PPR #1 on B 4
> 5. PPR #2 on B 5
> But, say we've configured Trinidad down to save only two
> state tokens (just for the sake of the example). Click
> the back button after request #5, and we'll be on Page A
> with state token 2 - but that token is gone, even though
> we've only gone back one page!
> What's lame here is that with PPR, we're caching all sorts
> of state tokens that are totally inaccessible (there's no way to
> get back to tokens 1, 3, or 4 after their respective requests).
> So: why not just reuse the existing state token on PPR?
> Request Token
> 1. Page A 1
> 2. PPR #1 on A 1
> 3. Page B 2
> 4. PPR #1 on B 2
> 5. PPR #2 on B 2
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.