[
https://issues.apache.org/jira/browse/TAPESTRY-2138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12627979#action_12627979
]
Geoff Callender commented on TAPESTRY-2138:
-------------------------------------------
I've gone off this idea as a common technique. That's because I've gone off
the idea of page1 calling page2.onActivate(context). I agree with the
convention that it should call something like page2.set(context) then do the
usual redirection, where page2 has this:
public void set(Long id) {
_personId = id;
}
long onPassivate(){
return _personId;
}
void onActivate(Long id) {
_personId = id;
_person = getPersonService().findPerson(_personId);
}
The reason is threefold:
- with T5's nice, more RESTful URLs, every page has to consider the possibility
of a bad activation context coming from a user tampering with the render
request URL in the browser and possibly have to deal with it on the same page,
ie. throwing an exception from onActivate() is often not a great idea;
- normal navigation through a web app is unlikely to produce a bad context, so
there's rarely a benefit in page1 calling page2.onActivate().
- I don't feel comfortable persisting stuff through the redirecton when it can
be avoided. People with clusters may agree.
@Persist("redirection") might still be handy, though, from time to time when
you really do have to pass an object from page1 to page2?
> @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.1
> 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]
