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

        

Mime
View raw message