Yes, I agree with that Norman. That's sort of what I implied when I said that I "always link to pages with initial context already set" - i.e. the reverse works better - re-initialize the page if a specific context is set. That's one way, what Howard suggests is another (identify page internal links) and third is to differentiate between an event and a render request. And of course, you can get it done by setting various semi-persistent (flash etc). flags etc.
Kalle On Tue, Dec 8, 2009 at 11:43 AM, Norman Franke <nor...@myasd.com> wrote: > I implemented a somewhat similar approach for search using an even more > basic approach. Most of my search fields are @Persisted, but I still needed > a way to know when to reset the search dialog. I ended up creating a new > context parameter, consisting of the string "reset". Every time I wanted to > create a blank search page, I'd send the reset parameter which would set all > of the @Persist-ed properties to null. (Using the context parameter to the > pagelink, one could even make that a custom component: NewSearch or > something.) Otherwise, it would use the values as-is. This allowed someone > to click on a result to get more details, but then come back with everything > as it was. Rather simple, but effective in my case. > > Norman Franke > Answering Service for Directors, Inc. > www.myasd.com > > > > On Dec 8, 2009, at 1:59 PM, Howard Lewis Ship wrote: > >> 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 >> > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
