tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Massimo Lusetti (JIRA)" <j...@apache.org>
Subject [jira] [Closed] (TAP5-158) @Persist("redirection")
Date Thu, 11 Aug 2011 22:06:27 GMT

     [ https://issues.apache.org/jira/browse/TAP5-158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Massimo Lusetti closed TAP5-158.

       Resolution: Won't Fix
    Fix Version/s: 5.3

Please open a new one for 5.3 if this still applicable

> @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
>             Fix For: 5.3
> 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message