Re: Is there a way of knowing if Tapestry is page rendering or event handling (was: Page render & event URLs with large optional context parameter)
On Mon, 22 Feb 2010 13:05:52 -0300, Blower, Andy wrote: Thanks for the reply Thiago. I'm pretty familiar with the methods in CELE (as I call it) but I'm not seeing what you're getting at. Is there something that Tapestry puts in the environment? AFAIK, no. You can file a JIRA for that. If I'm adding my own mechanism I'll be going with a simple Boolean flag in the page class that's set to true by setup render rather than adding/intercepting CELE methods. I was thinking about using CELE methods, not intercepting them. I decodePageRequest() returns true, it's rendering, and so on. -- Thiago H. de Paula Figueiredo Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor Owner, software architect and developer, Ars Machina Tecnologia da Informação Ltda. http://www.arsmachina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
RE: Is there a way of knowing if Tapestry is page rendering or event handling (was: Page render & event URLs with large optional context parameter)
Thanks for the reply Thiago. I'm pretty familiar with the methods in CELE (as I call it) but I'm not seeing what you're getting at. Is there something that Tapestry puts in the environment? If I'm adding my own mechanism I'll be going with a simple Boolean flag in the page class that's set to true by setup render rather than adding/intercepting CELE methods. > -Original Message- > From: Thiago H. de Paula Figueiredo [mailto:thiag...@gmail.com] > Sent: 22 February 2010 13:42 > To: Tapestry users > Subject: Re: Is there a way of knowing if Tapestry is page rendering or > event handling (was: Page render & event URLs with large optional > context parameter) > > On Mon, 22 Feb 2010 10:20:59 -0300, Blower, Andy > wrote: > > > So, how can I detect if Tapestry is rendering (and which page) from > > within the pages' onPassivate method? > > Take a look at the decode* methods in ComponentEventLinkEncoder. > > -- > Thiago H. de Paula Figueiredo > Independent Java, Apache Tapestry 5 and Hibernate consultant, > developer, > and instructor > Owner, software architect and developer, Ars Machina Tecnologia da > Informação Ltda. > http://www.arsmachina.com.br > > - > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org >
Re: Is there a way of knowing if Tapestry is page rendering or event handling (was: Page render & event URLs with large optional context parameter)
On Mon, 22 Feb 2010 10:20:59 -0300, Blower, Andy wrote: So, how can I detect if Tapestry is rendering (and which page) from within the pages' onPassivate method? Take a look at the decode* methods in ComponentEventLinkEncoder. -- Thiago H. de Paula Figueiredo Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor Owner, software architect and developer, Ars Machina Tecnologia da Informação Ltda. http://www.arsmachina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Is there a way of knowing if Tapestry is page rendering or event handling (was: Page render & event URLs with large optional context parameter)
Hi, and thanks for your reply to my previous enquiry Kalle. I have too many render links being generated to want to do that, but it did help me step back and come at the problem from a different angle. So what I'm thinking of now is having onPassivate only add the extra (optional) bit of the activation context if it's *not* rendering this particular page. So other pages will generate links to it with the extra AC param, by calling this pages' onPassivate. And the page itself when an event handler returns null will add the extra AC param in onPassivate because the page isn't rendering. When it is none of the links get the extra AC param. Only a problem if the page renders page links to itself, they will not be bookmarkable because the extra AC param is missing. This is not a problem because it doesn't link to render itself - always calls event handlers first. Note that the extra AC param can be generated from the session, so it doesn't need passing in the URL - it's only there in case the URL is bookmarked. So, how can I detect if Tapestry is rendering (and which page) from within the pages' onPassivate method? Is there a way, or do I need to add my own mechanism? (pretty simply by setting a Boolean flag in setup render..) Thanks, Andy > -Original Message- > From: Kalle Korhonen [mailto:kalle.o.korho...@gmail.com] > Sent: 16 February 2010 18:22 > To: Tapestry users > Subject: Re: Page render & event URLs with large optional context > parameter > > If you have a limited number of pagelinks referring to the same page, > maybe you could just contruct them by hand and just return null in > onPassivate. I.e. store the initial context to @Property > initialContext and then render the page links with page="mypage" context="initialContext"/> - would that work? > > Kalle > > > On Tue, Feb 16, 2010 at 9:54 AM, Blower, Andy > wrote: > > I may have enquired about this a while back, but I put it on the back > burner and am only just returning to it now. > > > > Basically I have a page with an activation context which is not > bookmarkable (relies on session info) without an extra parameter in the > activation context which contains all the info that allows the page to > be regenerated without the original session. This works fine, but the > issue is that the string is very long and it gets added to every event > link on the page even though it's completely useless except once the > session has the info in it - if the session times out and then one of > the event links is clicked there's a dispatcher to detect & redirect to > a session ended page with a login page following. So, it's only really > useful in page render URL's that appear in the browser location box and > can be bookmarked. > > > > Why worry about it, well, it increases the page size by 15-20%. > That's a lot and I want to come up with a way of only having this > context param in page render URL's. The page's activation handles it > being present or not perfectly, I'm just not sure how to make the > context that passivate returns conditional on the type of link being > generated. My only idea so far is to use call stack introspection to > see where the method was called from, but I'd rather not - seems quite > horrible. > > > > Anyone have any (more elegant and Tapestry-ish) ideas? > > > > Thanks, > > > > Andy Blower. > > > > - > 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
Re: Page render & event URLs with large optional context parameter
If you have a limited number of pagelinks referring to the same page, maybe you could just contruct them by hand and just return null in onPassivate. I.e. store the initial context to @Property initialContext and then render the page links with - would that work? Kalle On Tue, Feb 16, 2010 at 9:54 AM, Blower, Andy wrote: > I may have enquired about this a while back, but I put it on the back burner > and am only just returning to it now. > > Basically I have a page with an activation context which is not bookmarkable > (relies on session info) without an extra parameter in the activation context > which contains all the info that allows the page to be regenerated without > the original session. This works fine, but the issue is that the string is > very long and it gets added to every event link on the page even though it's > completely useless except once the session has the info in it - if the > session times out and then one of the event links is clicked there's a > dispatcher to detect & redirect to a session ended page with a login page > following. So, it's only really useful in page render URL's that appear in > the browser location box and can be bookmarked. > > Why worry about it, well, it increases the page size by 15-20%. That's a lot > and I want to come up with a way of only having this context param in page > render URL's. The page's activation handles it being present or not > perfectly, I'm just not sure how to make the context that passivate returns > conditional on the type of link being generated. My only idea so far is to > use call stack introspection to see where the method was called from, but I'd > rather not - seems quite horrible. > > Anyone have any (more elegant and Tapestry-ish) ideas? > > Thanks, > > Andy Blower. > - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Page render & event URLs with large optional context parameter
I may have enquired about this a while back, but I put it on the back burner and am only just returning to it now. Basically I have a page with an activation context which is not bookmarkable (relies on session info) without an extra parameter in the activation context which contains all the info that allows the page to be regenerated without the original session. This works fine, but the issue is that the string is very long and it gets added to every event link on the page even though it's completely useless except once the session has the info in it - if the session times out and then one of the event links is clicked there's a dispatcher to detect & redirect to a session ended page with a login page following. So, it's only really useful in page render URL's that appear in the browser location box and can be bookmarked. Why worry about it, well, it increases the page size by 15-20%. That's a lot and I want to come up with a way of only having this context param in page render URL's. The page's activation handles it being present or not perfectly, I'm just not sure how to make the context that passivate returns conditional on the type of link being generated. My only idea so far is to use call stack introspection to see where the method was called from, but I'd rather not - seems quite horrible. Anyone have any (more elegant and Tapestry-ish) ideas? Thanks, Andy Blower.
