Ah ... thanks James. I didn't realize that rendering a page would invoke onPassivate for the pages included via *link tags.
I need to look for and watch this happen ... thanks very much. -Luther On Tue, Dec 9, 2008 at 1:38 AM, James Hillyerd <[EMAIL PROTECTED]> wrote: > (I'm still learning to anyone feel free to correct me!) > > Think of it this way: onPassivate() is used to generate links to your a > page. Anytime you to t:pagelink, t:actionlink, or t:form - they all create > an instance of your page (even if you don't specify a context), then call > onPassivate on it. I *think* each link/form etc will create it's own > instance of the page (actually more likely fetching it from the cache) and > call onPassivate. So you could see this many times for a single .tml > render. > onActivate() doesn't necessarily need to be called first. You could > @Inject > a page, call a setter on it, and then return it from an event handler. I > think Tapestry would then call onPassivate and use that to generate the > redirect URL for the browser. Then when your browser requests that URL, > Tapestry will call the pages onActivate method to attempt restore the state > you wanted. > > Does that make sense? I know the labeling seems backwards, that's what > made > it hard for me to grasp - seems weird to passivate something that was never > activated! > > -james > > On Mon, Dec 8, 2008 at 7:19 PM, Luther Baker <[EMAIL PROTECTED]> > wrote: > > > Question about the flow. > > > > I GET ViewProject.tml with an activation context of "1" which invokes: > > ViewProject.onActivate(Integer projectId) > > > > I echo the projectId to the screen as a context for a CreateIssue > pagelink. > > I visit or GET CreateIssue.tml which invokes: > > CreateIssue.onActivate(Integer projectId) > > Createissue.onPassivate() > > > > > > *Q1*: ?? Why does onPassivate get called here - but not when I visited > > ViewProject ?? > > > > > > I complete two fields on the CreateIssue.tml form and submit the form to > > CreateIssue.java which invokes > > CreateIssue.onActivate(Integer projectId) > > CreateIssue.onSuccess() > > > > > > *Q2*: ?? Why isn't CreateIssue.onPassivate called ?? > > > > > > I return CreateIssue.onSuccess returns "ViewProject.class" which invokes: > > ViewProject.onPassivate() > > ViewProject.onActivate(Integer projectId) > > > > > > *Q3*: ?? Whoa? How'd that happen? I'm going TO ViewProject.tml --- and > yet, > > onPassivate is invoked first. obviously, ViewProject has NO IDEA what > > projectId to return since, it was invoked without an ACTIVATION context. > Is > > that why onPassivate is called? to find an activation context? I know the > > docs say that if no activation context is passed - Tapestry will ask the > > page for one. Is this how? If so - one need be a bit careful about how > > onPassivate is implemented? > > > > Is there an HttpSession free way to forward to have CreateIssue.onSuccess > > >> > > ViewProject.onActivate(Integer projectId) ? > > > > So - I'm not sure how I can forward to another page and pass an > activation > > context along with the forward ... Is there a way? After taking a look > > here, > > http://tapestry.apache.org/tapestry5/tapestry-core/guide/pagenav.html, I > > decided to try to @InjectPage so that > > > > CreateIssue.onSuccess() > > { > > nextPage.setProject(project); > > return nextPage; > > } > > > > and changed ViewProject.onPassivate() to return project.getId() ... > which, > > is naturally used by ViewProject.Activate(Integer projectId) which is > > called > > next. > > > > Does that seem like the right way to do this? I don't need to @Persist as > > the example has done - since with this method, I can cause onPassivate to > > return what onActivate needs ... and I really don't need to save this > info > > after the request is handled... But, is it safe to assume that the > instance > > of the page returned by CreateIssue will be the instance that handles the > > request ... ie: do I have a pooling concern when I'm directly assigning > > page > > properties? > > > > Man ... this is cool. > > > > -Luther > > > > > > -- > James A. Hillyerd <[EMAIL PROTECTED]> >
