[
https://issues.apache.org/jira/browse/TAPESTRY-2138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12566980#action_12566980
]
Geoff Callender commented on TAPESTRY-2138:
-------------------------------------------
The reason for testing if (_person == null) is to prevent finding person twice
- before and after a redirect. If page 1 has used page 2's onActivate during
an action request, then you may not want page 2 getting Person again in the
render phase. eg.
void onValidateFromForm() {
try {
_page2.onActivate(_personId);
}
catch (Exception e) {
_form.recordError(e.getMessage());
}
}
Object onSuccess() throws Exception {
return _page2;
}
As discussed in the mailing list recently, there are reasons you may prefer to
avoid persisting through the redirection, eg. in a clustered environment it
would create more replication traffic.
> @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]
