I've had to solve this problem for one of my clients as well and I think it's something that should go into the framework. The approach I took was to identify self-referential links (page render links that are to the same page they originate from) using an additional query parameter. This allows Tapestry to differentiate between requests that start on a new page vs. those that continue on the page. Tapestry can then fire a notification on components to perform initialization (on page render requests without the query parameter).
This would be a new lifecycle method, like pageAttached() or pageLoaded(). I'm still working on the right terminology, for Widen it is "initialized", as in method pageInitialized(). On Mon, Dec 7, 2009 at 10:22 PM, Kalle Korhonen <kalle.o.korho...@gmail.com> wrote: > Most things in T5 are delightfully simple, but I find this > surprisingly difficult: how to best initialize a page to default > context (and redirect to it). Imagine you have a search & result page. > If I access the page without any context I want all records to be > displayed. In onActivate() without parameters I set the context to > *all* and return this to redirect, then I query the database in > setupRender() to initialize the data for the grid. However, sorting > the grid will also cause a call to onActivate() without parameters, > resetting my data to the default context. The parameter-less call to > onActivate() would be harmless if I didn't do a redirect from > onActivate() but then I cannot set the default context and redirect. > In setupRender() I could decide whether redirect is needed or not but > at that time, I'm already committed to rendering the request. > > Because events cause a parameterless onActivate() call, I tend to > reserve onActivate() for possible component/event initialization needs > only and always link to pages with initial context already set. I also > find it roughly impossible to use overloaded versions of onActivate() > and subsequently, if my page has multiple entry points, I typically > resort to implementing it in a single onActivate(EventContext > eventContext) operation containing a big if-else clause. Since the > activation context is anyway sent with an event request (as in > ?t:ac=mycontext), rather than using the encoded context for rendering, > wouldn't it be just simpler if that context was used for activating > the page for the event request and the following redirect for > rendering would just use whatever context onPassivate() returns? What > do others think, how do you handle this? > > Kalle > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > > -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
