tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Millett <...@millett.net>
Subject Persistent Properties in 3.1
Date Thu, 11 Nov 2004 16:31:48 GMT
Hi all,

I've been following the users list for a couple of months and the 
developers list for a couple of weeks. I think Tapestry is a great 
framework and I continue to enjoy it the more I dig into it. I am 
excited for the new release and just wanted to chip in my 2 cents based 
on my experience of the last 2 months.

Following up on the persistent properties thread:

I second Jaime's idea. If the page properties are persisted in the query 
string, a user could have, for example, 3 copies of a product detail 
page open each pointing to a different product based on a product id 
property persisted in the query string. This is a little awkward to 
implement now because you have to choose between a) using a persistent 
property to store the id which doesn't allow the user to have multiple 
instances of the page open and b) forcing any directLinks on the page 
(e.g. Buy button, or Add to Favorites button) to pass the product id 
through their own listener and back to the parent page so it can 
properly render itself. Another thing nice about using the query string 
model is that each instance of a page the user has open is self 
sufficient. It contains all its own state and remains valid for as long 
as the user keeps it around.

I could also imagine the ability to define a property set for a group of 
pages. Where the set of properties would keep persisting through the 
query string (or session) until the user navigated away from that set of 
pages. I presume this might be an alternative way to approach the 
prescribed path notion (which I didn't see).

Another flow pattern I have used in multiple places in my app is that of 
call and return. I implemented a mechanism where my page validate 
function when necessary implements a function call to another set of 
pages. It creates a unique id for the call and persists a set of 
parameters including a return page/callback which are then looked up by 
the called page. Once the called page (or set of pages) completes, the 
return/callback is executed and the call stack released. It would be 
great if the framework handled this too.

As a side note to get the call and return working for my use case, I 
created a FormCallback which encapsulates a form post. When the callback 
is executed in a later request cycle, a FormRedirectException (extends 
PageRedirectException) is thrown to pass control to a modified 
DirectService which then services the form post (with rewinding etc) 
just as it would have happened originally. I'm not sure how generally 
useful this is, but I used it to interrupt a form post with a password 
confirmation page and then if the password was correct, submit the 
original form post with no further user interaction.

Phew! If you made it this far, thanks for bearing with me :-)
I hope some useful information was transmitted.



To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org

View raw message