Yes, you have it right.  

PageLink, IMO, is working correctly according to the client persistence
specs.  I just don't like sullying my beautiful beautiful URL space :) 

Storing state on the client -- especially for a public application like
ours -- is very frequently preferable.  However, you only have a couple
of options.  Cookies, which users might turn off, you might run into
data size  limitation issues, and some browsers don't handle the sharing
across tabs/windows well.  Or you have URL mucking (like T4), which
solves those problems but introduces ugly encoded messes on all the
links.  In Zillow's case, individual page requests are always
effectively stateless (or only require server-side session state), so
only forms needed to be covered.  One of the things I love about
Tapestry is that it made it simple to introduce our own persistence
strategy that did exactly what I wanted.

jeff

-----Original Message-----
From: news [mailto:[EMAIL PROTECTED] On Behalf Of Geoff Callender
Sent: Tuesday, April 04, 2006 2:09 AM
To: [email protected]
Subject: RE: Why does PageLink include state in the URL?


Jeff Lubetkin <jefflub <at> zillow.com> writes:

> 
> Done.  http://wiki.apache.org/jakarta-tapestry/FormClientPersistence
> 
> I did that pretty quickly, so please let me know if you have any
> questions.
> 
> jeff
> 

But the question remains - why should PageLink EVER return state?  
How could the next page even read it?

Any takers?

Jeff, your solution is a beautifully simple workaround - 
@Persist("client:form") instructs Tapestry to send the data out (hidden 
on the page) and only return it when there's a POST (eg. by submit 
button on a form) but not a GET (eg. when PageLink, DirectLink, or 
ExternalLink is called). Jeff, have I got it right?

I've tried it and it looks like a very neat improvement on
FormLinkRenderer - 
Jeff's solution writes the state only once to the html, whereas 
FormLinkRenderer writes it to the html once per link!)

Geoff



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to