[
https://issues.apache.org/jira/browse/TAP5-158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12779519#action_12779519
]
mindhawk commented on TAP5-158:
-------------------------------
I would want to call this strategy "transaction", which means the data only
persist from the user send a request to the responses returned to the browser.
This would not make much data on the server and more clear to understand than
flash
> @Persist("redirection")
> -----------------------
>
> Key: TAP5-158
> URL: https://issues.apache.org/jira/browse/TAP5-158
> Project: Tapestry 5
> Issue Type: New Feature
> Affects Versions: 5.0.15
> Reporter: Geoff Callender
> Priority: Minor
>
> Suggesting a new persistence strategy, @Persist("redirection"), which is a
> fine-tuning of "flash" to a specific, very common, requirement. It would be
> semantically clearer and less prone to errors than using "flash".
> It's common to want persistence of an object during the redirection portion
> of an action request, and not between render requests. Using "flash" it's
> common to do this:
> @Persist("flash")
> private Person _person;
> void onActivate(Long id) throws Exception {
> _personId = id;
> if (_person == null) {
> _person = getPersonService().findPerson(_personId);
> }
> }
> However, it has a problem - every 2nd time you reload/refresh the page (which
> is a render request), _person will not be refreshed because every 2nd time it
> won't be null. This is disconcerting and pretty much incorrect behaviour.
> A solution is to nullify _person in cleanupRender(). But if we do that then
> we're not really using "flash" any more. It may as well be "session". And
> it's easy to forget to nullify _person, and it's less obvious to the reader.
> So..... how about @Persist("redirection") whose intention is absolutely clear
> and will work correctly without the programmer adding to cleanupRender()?
> To be extra-clever, an enhancement may be to persist it with a temporary
> conversation-id behind the scenes, making it absolutely impossible for two
> windows in the same session to accidentally collide on it during concurrent
> redirections.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
