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
