Yeah, I could've done something with PageValidateListener, but I was just trying to point out that some of the link components are session aware and some aren't. Sometimes they behave differently than you would expect (and it isn't always documented). I was quite happy with a DirectLink showing the stale session page when the session expired and that's all I wanted PageLink to do, too. I'm not too concerned with bookmarks/etc since the application requires a valid login/session to do anything. The only page that doesn't require a session is the Home page (login).
Anyway, didn't mean to hijack the original poster's topic. Thanks, /dev/mrg -----Original Message----- From: Jeff Lubetkin [mailto:[EMAIL PROTECTED] Sent: Monday, April 03, 2006 3:02 PM To: Tapestry users Subject: RE: Why does PageLink include state in the URL? That does make sense. We handle this by simply having our base page class validate the server-side session (using PageValidateListener) and send the user to the right place (sounds like the stale session page, in your case). This prevents session problems no matter how the user gets there. For instance, what would happen if the user bookmarked the page that required state, or emailed the URL to a friend? jeff -----Original Message----- From: Gentry, Michael (Contractor) [mailto:[EMAIL PROTECTED] Sent: Monday, April 03, 2006 10:49 AM To: Tapestry users Subject: RE: Why does PageLink include state in the URL? By not being session-aware, I mean: * User is using session-based application * Goes away for a period of time, session expires * Comes back and clicks on navigation link (Home, Summary, etc) When I used PageLink for the navigation links (the general-purpose, high-level ones, not action-oriented ones), I found that Tapestry transfers control and starts to render the specified page, such as the Summary. During the render, the Summary page accesses the session object to pull user-specific details out. That's when the NPE occurs and Tapestry generates the huge exception page. PageLink transfers control directly to a page without concern for sessions and I didn't see a way to ask the PageLink to check for a session. I suppose some could argue this is a feature. When I use DirectLink, it checks for a stale session before transferring control to the new page. When the session has expired, it renders the much friendlier stale session page instead of generating the huge exception page. So ... DirectLink seems to be session-aware while PageLink does not. Hope that made sense. Also, on a side note, does anyone know why Tapestry has so many link components? I also use WebObjects and it only has one link -- WOHyperLink. It does ActionLink, DirectLink, PageLink, ExternalLink, etc all in one. Seems much simpler to me. Thanks, /dev/mrg -----Original Message----- From: Jeff Lubetkin [mailto:[EMAIL PROTECTED] Sent: Monday, April 03, 2006 11:59 AM To: Tapestry users Subject: RE: Why does PageLink include state in the URL? We use both server side and client side persistence at Zillow. We've had no problems with server session and PageLink, but we did have the same problem as Geoff, where client persisted data ended up on too many URLs. What we really wanted was for the data to persist across form submissions only, so that when the page containing a form re-rendered due to a validation failure, it had all of its necessary data available. We solved this by creating a new client persistence strategy that only encodes the persisted state to URLs that are being used in a post. The code is trivial, it works great, and I can share it on the wiki if there's interest. jeff PS Not sure what you mean by @PageLink not being "session-aware", Michael. For cookied users, linking a client back to the session is entirely up to the servlet container. For non-cookied users, the only servlet obligation is to pass URLs through the encoder, which PageLink does. Can you characterize your problem better? -----Original Message----- From: Gentry, Michael (Contractor) [mailto:[EMAIL PROTECTED] Sent: Monday, April 03, 2006 7:50 AM To: Tapestry users Subject: RE: Why does PageLink include state in the URL? I find this a bit interesting because in my experience, @PageLink has ignored my session scoped data (it is not session-aware), which kept resulting in NPEs (and the nasty exception page for users) on my navigation links when the session timed out (all of my pages use session data to render). My workaround for that was to switch everything to use @DirectLink and call a silly listener method: public String gotoPage(String pageName) { return pageName; } And then in the .html: <a href="#" jwcid="@DirectLink" listener="listener:gotoPage" parameters="literal:Home">...</a> I don't know if such a technique would be helpful for you or not (I've not used client-side persistence). /dev/mrg -----Original Message----- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Geoff Callender Sent: Monday, April 03, 2006 10:27 AM To: [email protected] Subject: Why does PageLink include state in the URL? When my page has @Persist("client") on some properties, the state becomes included in the URL of PageLinks. eg. <a href="/perspectives/app?page=web%2Fmain% 2FTestsPage&service=page&state:Home=BrO0ABXcOAAAAAQAAB3N0cmluZ3 NzcgATamF2YS51dGlsLkFycmF5TGlzdHiB0h2Zx2GdAwABSQAEc2l6ZXhwAAAA A3cEAAAACnQABUZpcnN0dAAGU2Vjb25kdAAFVGhpcmR4">PageLink</a> Does this serve a purpose? The problem is that when the URL becomes too long then the link fails silently. But all I want to do is go to a different page with a link on the navigation bar, regardless of the data on the current page. 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] --------------------------------------------------------------------- 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] --------------------------------------------------------------------- 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]
