Use session persistence and clear the fields inside afterRender(). On Thu, Nov 6, 2008 at 1:19 PM, Fernando Padilla <[EMAIL PROTECTED]> wrote: > I'll say that it addresses the intended usecase, but not "correctly". :) > > Intended to survive until the page is "rendered". And as long as you > require that the page is the next one rendered without any intervening > requests then yes, it fulfills the requirement. I'm just saying that as the > pages get more complicated and have more ajaxy requests, the lifespan of > these variables will be much shorter than expected. And I'm getting bit by > it at the moment. > > I know that it might be too big for you to actively change this now, but do > you have any ideas? I don't mind putting in some sweat to fix this since > this is affecting us right now! :) > > For us making the Form use session persist instead of flash persist will fix > it except for minor side effects. Do you have any other ideas? > > > > Howard M. Lewis Ship (JIRA) wrote: >> >> [ >> https://issues.apache.org/jira/browse/TAP5-320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12645584#action_12645584 >> ] >> Howard M. Lewis Ship commented on TAP5-320: >> ------------------------------------------- >> >> The intent of flash is to store a value long enough for it to be rendered >> on the same page in the next (render) request. >> >> So, I understand that it's not doing what you want, and there is some >> ambiguity in how it operates ... but it does correctly address the use case >> it was created for. >> >>> Flash Persist Variables might be cleared too aggressively >>> --------------------------------------------------------- >>> >>> Key: TAP5-320 >>> URL: https://issues.apache.org/jira/browse/TAP5-320 >>> Project: Tapestry 5 >>> Issue Type: Bug >>> Components: tapestry-core >>> Affects Versions: 5.0.16 >>> Reporter: Fernando >>> >>> So yes it looks like the Flash variables of a Page are scrubbed when the >>> page is removed from the cache, no matter if it's rendered or not. The >>> stack trace is below. >>> I know that my example might be a bit extreme, but here are some other >>> usecases that should be affected as well: >>> -- Page Rendering >>> 1) render PageA (set flash variable). >>> 2) render PageB >>> a) while rendering, it loads PageA for some reason >>> (RequestPageCache.get, PageLink, ActionLink, etc) >>> b) while loading PageA, its flash variables are cleared >>> 3) render PageA (flash variable is null) >>> -- Ajax >>> 1) render PageA (set flash variable). >>> 2) Ajax callback to app >>> a) either hitting PageA directly, or hitting PageB that >>> refers to PageA in some way >>> ( PageLink, ActionLink, RequestPageCache.get ) >>> b) while loading PageA, its flash variables are cleared >>> 3) render PageA (flash variable is null) >>> STACK TRACE: >>> showing that flash variables are cleared from pages once they are loaded, >>> not once they are rendered, so it can be cleared way before we have a change >>> to render it. >>> setAttribute( flash:core/Start:status.cheerform:defaultTracker, null ) >>> at >>> org.apache.tapestry5.internal.services.SessionImpl.setAttribute(SessionImpl.java:50) >>> at >>> org.apache.tapestry5.internal.services.FlashPersistentFieldStrategy.didReadChange(FlashPersistentFieldStrategy.java:41) >>> at >>> org.apache.tapestry5.internal.services.AbstractSessionPersistentFieldStrategy.gatherFieldChanges(AbstractSessionPersistentFieldStrategy.java:65) >>> at >>> org.apache.tapestry5.internal.services.PersistentFieldManagerImpl.gatherChanges(PersistentFieldManagerImpl.java:65) >>> at >>> $PersistentFieldManager_11d5412d051.gatherChanges($PersistentFieldManager_11d5412d051.java) >>> at >>> org.apache.tapestry5.internal.structure.PageImpl.getFieldChange(PageImpl.java:185) >>> at >>> org.apache.tapestry5.internal.structure.InternalComponentResourcesImpl.getFieldChange(InternalComponentResourcesImpl.java:111) >>> at >>> org.apache.tapestry5.internal.structure.InternalComponentResourcesImpl.hasFieldChange(InternalComponentResourcesImpl.java:121) >>> at >>> com.protrade.fanwars.base.pages.Start.containingPageDidAttach(Start.java) >>> at >>> org.apache.tapestry5.internal.structure.ComponentPageElementImpl$2.run(ComponentPageElementImpl.java:80) >>> at >>> org.apache.tapestry5.internal.structure.ComponentPageElementImpl.invoke(ComponentPageElementImpl.java:912) >>> at >>> org.apache.tapestry5.internal.structure.ComponentPageElementImpl.containingPageDidAttach(ComponentPageElementImpl.java:726) >>> at >>> org.apache.tapestry5.internal.structure.PageImpl.attached(PageImpl.java:151) >>> at >>> org.apache.tapestry5.internal.services.RequestPageCacheImpl.get(RequestPageCacheImpl.java:55) >>> at >>> $RequestPageCache_11d5412d04b.get($RequestPageCache_11d5412d04b.java) >>> at >>> $RequestPageCache_11d5412d046.get($RequestPageCache_11d5412d046.java) >>> at >>> com.protrade.facebook.base.services.FbForceModeFilter.handle(FbForceModeFilter.java:57) >>> (this is my PageRenderRequestFilter which cuts off page rendering) >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
-- Howard M. Lewis Ship Creator Apache Tapestry and Apache HiveMind --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
