[
https://issues.apache.org/jira/browse/TAPESTRY-2138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12566972#action_12566972
]
Igor Drobiazko commented on TAPESTRY-2138:
------------------------------------------
You don't need to persist the person. Just return the id of the person in the
passivate method.
http://tapestry.formos.com/nightly/tapestry5/tapestry-core/guide/pagenav.html
void onActivate(Long id) {
_personId = id;
_person = getPersonService().findPerson(_personId);
}
long onPassivate(){
return _personId;
}
The state of the page will be restored from the activation context.
> @Persist("redirection")
> -----------------------
>
> Key: TAPESTRY-2138
> URL: https://issues.apache.org/jira/browse/TAPESTRY-2138
> Project: Tapestry
> Issue Type: New Feature
> Components: tapestry-core
> Affects Versions: 5.0 Next Release
> 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
