You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Juan Isern <ju...@gmail.com> on 2010/04/14 22:01:00 UTC

Good practices for handling page cleanup

Guys, I've been working with some ajax components that need, to work
properly, to store data in the session as persistent fields.

I thought onActivate() would be a nice place to clean things up, doing it at
the very first moment that a page is requested by the user seems ok.

The problem is that onActivate() gets invoked during ajax requests too. 

Is it any way to determine when a request comes from a user that's entered
an address or followed a link to that page, and make sure that request does
not come from ajax or an action link on it? I think that'd be my requirement

Thanks again, Juan
-- 
View this message in context: http://old.nabble.com/Good-practices-for-handling-page-cleanup-tp28247499p28247499.html
Sent from the Tapestry - User mailing list archive at Nabble.com.


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


Re: Good practices for handling page cleanup

Posted by Inge Solvoll <in...@gmail.com>.
That's excellent news, I've been struggling with something related to this
lately. Looking forward to upgrading :)

On Mon, Apr 19, 2010 at 3:02 PM, Howard Lewis Ship <hl...@gmail.com> wrote:

> This is easier in Tapestry 5.2.
>
> A new lifecycle method, pageReset(), is available (on pages or components).
>
> When a page is first accessed (from another page), the pageReset()
> lifecycle method is invoked.  If you stay on the page (component
> events, ajax events, or page render requests for the same page) then
> no pageReset.  It's when you return to a page from some other page
> that the page is reset.
>
> On Sun, Apr 18, 2010 at 10:01 PM, Juan Isern <ju...@gmail.com> wrote:
> >
> > In case someone's interested...
> >
> > The solution was as simple as:
> >
> > @Inject
> > private ComponentEventLinkEncoder cele;
> >
> > (...)
> > return cele.decodePageRenderRequest(request) != null &&
> >                cele.decodeComponentEventRequest(request) == null;
> >
> > if that expression is true, then it's a fresh page request and it's safe
> to
> > clean up the session state, which can be achieved by doing:
> >
> > componentResources.discardPersistentFieldChanges();
> >
> > :)
> >
> > Cheerz
> >
> >
> > Juan Isern wrote:
> >>
> >> Alfie, thanks.
> >>
> >> It seems that the isXHR() approach will be good enough but it's nice to
> >> know of other mechanisms in the case the thing gets too complex.
> >>
> >>
> >> Alfie Kirkpatrick wrote:
> >>>
> >>> There's been some discussion on this in the past. The easiest way if
> AJAX
> >>> is your only scenario is probably using request.isXHR(). An alternative
> >>> is to maybe use the ComponentEventLinkEncoder either directly or by
> >>> intercepting it. It knows whether the request is for a page or
> component
> >>> event.
> >>>
> >>> http://markmail.org/message/mug7wv5gueuw6hhj
> >>> http://markmail.org/message/gds72nly2vk5sqm3
> >>>
> >>> Hope it helps,
> >>> Alfie.
> >>>
> >>> -----Original Message-----
> >>> From: Juan Isern [mailto:juanisern@gmail.com]
> >>> Sent: 14 April 2010 21:01
> >>> To: users@tapestry.apache.org
> >>> Subject: Good practices for handling page cleanup
> >>>
> >>>
> >>> Guys, I've been working with some ajax components that need, to work
> >>> properly, to store data in the session as persistent fields.
> >>>
> >>> I thought onActivate() would be a nice place to clean things up, doing
> it
> >>> at
> >>> the very first moment that a page is requested by the user seems ok.
> >>>
> >>> The problem is that onActivate() gets invoked during ajax requests too.
> >>>
> >>> Is it any way to determine when a request comes from a user that's
> >>> entered
> >>> an address or followed a link to that page, and make sure that request
> >>> does
> >>> not come from ajax or an action link on it? I think that'd be my
> >>> requirement
> >>>
> >>> Thanks again, Juan
> >>> --
> >>> View this message in context:
> >>>
> http://old.nabble.com/Good-practices-for-handling-page-cleanup-tp28247499p28247499.html
> >>> Sent from the Tapestry - User mailing list archive at Nabble.com.
> >>>
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >>> For additional commands, e-mail: users-help@tapestry.apache.org
> >>>
> >>>
> >>>
> >>
> >>
> >
> > --
> > View this message in context:
> http://old.nabble.com/Good-practices-for-handling-page-cleanup-tp28247499p28287213.html
> > Sent from the Tapestry - User mailing list archive at Nabble.com.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@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-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>

Re: Good practices for handling page cleanup

Posted by Howard Lewis Ship <hl...@gmail.com>.
I suppose such a callback would be possible, but there would be some
cost: if page X has such cleanup, then any link from page X to another
page will get an additional query parameter to identify it as sourced
on page X (so that when the request for page Y is processed, page X
can be cleaned up via a new lifecycle method).

So ... doable, but very intrusive.  Part of T5's appeal is the
concise, readable, SEO-compatible URLs, something a WO programmer will
not be used to.

On Mon, Apr 19, 2010 at 8:52 AM, Michael Gentry <mg...@masslight.net> wrote:
> Sweet!  This is something I've really missed (especially coming from a
> WebObjects background).  Is there another lifecycle method for when
> you leave a page (including through a PageLink)?  I tend to persist a
> lot of stuff in the session (lists of rows from the database, for
> example) that I could potentially toss as I'm leaving the page to free
> up memory.
>
> Thanks,
>
> mrg
>
>
> On Mon, Apr 19, 2010 at 9:02 AM, Howard Lewis Ship <hl...@gmail.com> wrote:
>> This is easier in Tapestry 5.2.
>>
>> A new lifecycle method, pageReset(), is available (on pages or components).
>>
>> When a page is first accessed (from another page), the pageReset()
>> lifecycle method is invoked.  If you stay on the page (component
>> events, ajax events, or page render requests for the same page) then
>> no pageReset.  It's when you return to a page from some other page
>> that the page is reset.
>>
>> On Sun, Apr 18, 2010 at 10:01 PM, Juan Isern <ju...@gmail.com> wrote:
>>>
>>> In case someone's interested...
>>>
>>> The solution was as simple as:
>>>
>>> @Inject
>>> private ComponentEventLinkEncoder cele;
>>>
>>> (...)
>>> return cele.decodePageRenderRequest(request) != null &&
>>>                cele.decodeComponentEventRequest(request) == null;
>>>
>>> if that expression is true, then it's a fresh page request and it's safe to
>>> clean up the session state, which can be achieved by doing:
>>>
>>> componentResources.discardPersistentFieldChanges();
>>>
>>> :)
>>>
>>> Cheerz
>>>
>>>
>>> Juan Isern wrote:
>>>>
>>>> Alfie, thanks.
>>>>
>>>> It seems that the isXHR() approach will be good enough but it's nice to
>>>> know of other mechanisms in the case the thing gets too complex.
>>>>
>>>>
>>>> Alfie Kirkpatrick wrote:
>>>>>
>>>>> There's been some discussion on this in the past. The easiest way if AJAX
>>>>> is your only scenario is probably using request.isXHR(). An alternative
>>>>> is to maybe use the ComponentEventLinkEncoder either directly or by
>>>>> intercepting it. It knows whether the request is for a page or component
>>>>> event.
>>>>>
>>>>> http://markmail.org/message/mug7wv5gueuw6hhj
>>>>> http://markmail.org/message/gds72nly2vk5sqm3
>>>>>
>>>>> Hope it helps,
>>>>> Alfie.
>>>>>
>>>>> -----Original Message-----
>>>>> From: Juan Isern [mailto:juanisern@gmail.com]
>>>>> Sent: 14 April 2010 21:01
>>>>> To: users@tapestry.apache.org
>>>>> Subject: Good practices for handling page cleanup
>>>>>
>>>>>
>>>>> Guys, I've been working with some ajax components that need, to work
>>>>> properly, to store data in the session as persistent fields.
>>>>>
>>>>> I thought onActivate() would be a nice place to clean things up, doing it
>>>>> at
>>>>> the very first moment that a page is requested by the user seems ok.
>>>>>
>>>>> The problem is that onActivate() gets invoked during ajax requests too.
>>>>>
>>>>> Is it any way to determine when a request comes from a user that's
>>>>> entered
>>>>> an address or followed a link to that page, and make sure that request
>>>>> does
>>>>> not come from ajax or an action link on it? I think that'd be my
>>>>> requirement
>>>>>
>>>>> Thanks again, Juan
>>>>> --
>>>>> View this message in context:
>>>>> http://old.nabble.com/Good-practices-for-handling-page-cleanup-tp28247499p28247499.html
>>>>> Sent from the Tapestry - User mailing list archive at Nabble.com.
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>> --
>>> View this message in context: http://old.nabble.com/Good-practices-for-handling-page-cleanup-tp28247499p28287213.html
>>> Sent from the Tapestry - User mailing list archive at Nabble.com.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@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-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: Good practices for handling page cleanup

Posted by Michael Gentry <mg...@masslight.net>.
Sweet!  This is something I've really missed (especially coming from a
WebObjects background).  Is there another lifecycle method for when
you leave a page (including through a PageLink)?  I tend to persist a
lot of stuff in the session (lists of rows from the database, for
example) that I could potentially toss as I'm leaving the page to free
up memory.

Thanks,

mrg


On Mon, Apr 19, 2010 at 9:02 AM, Howard Lewis Ship <hl...@gmail.com> wrote:
> This is easier in Tapestry 5.2.
>
> A new lifecycle method, pageReset(), is available (on pages or components).
>
> When a page is first accessed (from another page), the pageReset()
> lifecycle method is invoked.  If you stay on the page (component
> events, ajax events, or page render requests for the same page) then
> no pageReset.  It's when you return to a page from some other page
> that the page is reset.
>
> On Sun, Apr 18, 2010 at 10:01 PM, Juan Isern <ju...@gmail.com> wrote:
>>
>> In case someone's interested...
>>
>> The solution was as simple as:
>>
>> @Inject
>> private ComponentEventLinkEncoder cele;
>>
>> (...)
>> return cele.decodePageRenderRequest(request) != null &&
>>                cele.decodeComponentEventRequest(request) == null;
>>
>> if that expression is true, then it's a fresh page request and it's safe to
>> clean up the session state, which can be achieved by doing:
>>
>> componentResources.discardPersistentFieldChanges();
>>
>> :)
>>
>> Cheerz
>>
>>
>> Juan Isern wrote:
>>>
>>> Alfie, thanks.
>>>
>>> It seems that the isXHR() approach will be good enough but it's nice to
>>> know of other mechanisms in the case the thing gets too complex.
>>>
>>>
>>> Alfie Kirkpatrick wrote:
>>>>
>>>> There's been some discussion on this in the past. The easiest way if AJAX
>>>> is your only scenario is probably using request.isXHR(). An alternative
>>>> is to maybe use the ComponentEventLinkEncoder either directly or by
>>>> intercepting it. It knows whether the request is for a page or component
>>>> event.
>>>>
>>>> http://markmail.org/message/mug7wv5gueuw6hhj
>>>> http://markmail.org/message/gds72nly2vk5sqm3
>>>>
>>>> Hope it helps,
>>>> Alfie.
>>>>
>>>> -----Original Message-----
>>>> From: Juan Isern [mailto:juanisern@gmail.com]
>>>> Sent: 14 April 2010 21:01
>>>> To: users@tapestry.apache.org
>>>> Subject: Good practices for handling page cleanup
>>>>
>>>>
>>>> Guys, I've been working with some ajax components that need, to work
>>>> properly, to store data in the session as persistent fields.
>>>>
>>>> I thought onActivate() would be a nice place to clean things up, doing it
>>>> at
>>>> the very first moment that a page is requested by the user seems ok.
>>>>
>>>> The problem is that onActivate() gets invoked during ajax requests too.
>>>>
>>>> Is it any way to determine when a request comes from a user that's
>>>> entered
>>>> an address or followed a link to that page, and make sure that request
>>>> does
>>>> not come from ajax or an action link on it? I think that'd be my
>>>> requirement
>>>>
>>>> Thanks again, Juan
>>>> --
>>>> View this message in context:
>>>> http://old.nabble.com/Good-practices-for-handling-page-cleanup-tp28247499p28247499.html
>>>> Sent from the Tapestry - User mailing list archive at Nabble.com.
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>
>>>>
>>>>
>>>
>>>
>>
>> --
>> View this message in context: http://old.nabble.com/Good-practices-for-handling-page-cleanup-tp28247499p28287213.html
>> Sent from the Tapestry - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@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-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>

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


Re: Good practices for handling page cleanup

Posted by Howard Lewis Ship <hl...@gmail.com>.
This is easier in Tapestry 5.2.

A new lifecycle method, pageReset(), is available (on pages or components).

When a page is first accessed (from another page), the pageReset()
lifecycle method is invoked.  If you stay on the page (component
events, ajax events, or page render requests for the same page) then
no pageReset.  It's when you return to a page from some other page
that the page is reset.

On Sun, Apr 18, 2010 at 10:01 PM, Juan Isern <ju...@gmail.com> wrote:
>
> In case someone's interested...
>
> The solution was as simple as:
>
> @Inject
> private ComponentEventLinkEncoder cele;
>
> (...)
> return cele.decodePageRenderRequest(request) != null &&
>                cele.decodeComponentEventRequest(request) == null;
>
> if that expression is true, then it's a fresh page request and it's safe to
> clean up the session state, which can be achieved by doing:
>
> componentResources.discardPersistentFieldChanges();
>
> :)
>
> Cheerz
>
>
> Juan Isern wrote:
>>
>> Alfie, thanks.
>>
>> It seems that the isXHR() approach will be good enough but it's nice to
>> know of other mechanisms in the case the thing gets too complex.
>>
>>
>> Alfie Kirkpatrick wrote:
>>>
>>> There's been some discussion on this in the past. The easiest way if AJAX
>>> is your only scenario is probably using request.isXHR(). An alternative
>>> is to maybe use the ComponentEventLinkEncoder either directly or by
>>> intercepting it. It knows whether the request is for a page or component
>>> event.
>>>
>>> http://markmail.org/message/mug7wv5gueuw6hhj
>>> http://markmail.org/message/gds72nly2vk5sqm3
>>>
>>> Hope it helps,
>>> Alfie.
>>>
>>> -----Original Message-----
>>> From: Juan Isern [mailto:juanisern@gmail.com]
>>> Sent: 14 April 2010 21:01
>>> To: users@tapestry.apache.org
>>> Subject: Good practices for handling page cleanup
>>>
>>>
>>> Guys, I've been working with some ajax components that need, to work
>>> properly, to store data in the session as persistent fields.
>>>
>>> I thought onActivate() would be a nice place to clean things up, doing it
>>> at
>>> the very first moment that a page is requested by the user seems ok.
>>>
>>> The problem is that onActivate() gets invoked during ajax requests too.
>>>
>>> Is it any way to determine when a request comes from a user that's
>>> entered
>>> an address or followed a link to that page, and make sure that request
>>> does
>>> not come from ajax or an action link on it? I think that'd be my
>>> requirement
>>>
>>> Thanks again, Juan
>>> --
>>> View this message in context:
>>> http://old.nabble.com/Good-practices-for-handling-page-cleanup-tp28247499p28247499.html
>>> Sent from the Tapestry - User mailing list archive at Nabble.com.
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>>>
>>>
>>
>>
>
> --
> View this message in context: http://old.nabble.com/Good-practices-for-handling-page-cleanup-tp28247499p28287213.html
> Sent from the Tapestry - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@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-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


RE: Good practices for handling page cleanup

Posted by Juan Isern <ju...@gmail.com>.
In case someone's interested...

The solution was as simple as:

@Inject
private ComponentEventLinkEncoder cele;

(...)
return cele.decodePageRenderRequest(request) != null &&
                cele.decodeComponentEventRequest(request) == null;

if that expression is true, then it's a fresh page request and it's safe to
clean up the session state, which can be achieved by doing:

componentResources.discardPersistentFieldChanges();

:)

Cheerz


Juan Isern wrote:
> 
> Alfie, thanks.
> 
> It seems that the isXHR() approach will be good enough but it's nice to
> know of other mechanisms in the case the thing gets too complex.
> 
> 
> Alfie Kirkpatrick wrote:
>> 
>> There's been some discussion on this in the past. The easiest way if AJAX
>> is your only scenario is probably using request.isXHR(). An alternative
>> is to maybe use the ComponentEventLinkEncoder either directly or by
>> intercepting it. It knows whether the request is for a page or component
>> event.
>> 
>> http://markmail.org/message/mug7wv5gueuw6hhj
>> http://markmail.org/message/gds72nly2vk5sqm3
>> 
>> Hope it helps,
>> Alfie.
>> 
>> -----Original Message-----
>> From: Juan Isern [mailto:juanisern@gmail.com] 
>> Sent: 14 April 2010 21:01
>> To: users@tapestry.apache.org
>> Subject: Good practices for handling page cleanup
>> 
>> 
>> Guys, I've been working with some ajax components that need, to work
>> properly, to store data in the session as persistent fields.
>> 
>> I thought onActivate() would be a nice place to clean things up, doing it
>> at
>> the very first moment that a page is requested by the user seems ok.
>> 
>> The problem is that onActivate() gets invoked during ajax requests too. 
>> 
>> Is it any way to determine when a request comes from a user that's
>> entered
>> an address or followed a link to that page, and make sure that request
>> does
>> not come from ajax or an action link on it? I think that'd be my
>> requirement
>> 
>> Thanks again, Juan
>> -- 
>> View this message in context:
>> http://old.nabble.com/Good-practices-for-handling-page-cleanup-tp28247499p28247499.html
>> Sent from the Tapestry - User mailing list archive at Nabble.com.
>> 
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>> 
>> 
>> 
> 
> 

-- 
View this message in context: http://old.nabble.com/Good-practices-for-handling-page-cleanup-tp28247499p28287213.html
Sent from the Tapestry - User mailing list archive at Nabble.com.


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


RE: Good practices for handling page cleanup

Posted by Juan Isern <ju...@gmail.com>.
Alfie, thanks.

It seems that the isXHR() approach will be good enough but it's nice to know
of other mechanisms in the case the thing gets too complex.


Alfie Kirkpatrick wrote:
> 
> There's been some discussion on this in the past. The easiest way if AJAX
> is your only scenario is probably using request.isXHR(). An alternative is
> to maybe use the ComponentEventLinkEncoder either directly or by
> intercepting it. It knows whether the request is for a page or component
> event.
> 
> http://markmail.org/message/mug7wv5gueuw6hhj
> http://markmail.org/message/gds72nly2vk5sqm3
> 
> Hope it helps,
> Alfie.
> 
> -----Original Message-----
> From: Juan Isern [mailto:juanisern@gmail.com] 
> Sent: 14 April 2010 21:01
> To: users@tapestry.apache.org
> Subject: Good practices for handling page cleanup
> 
> 
> Guys, I've been working with some ajax components that need, to work
> properly, to store data in the session as persistent fields.
> 
> I thought onActivate() would be a nice place to clean things up, doing it
> at
> the very first moment that a page is requested by the user seems ok.
> 
> The problem is that onActivate() gets invoked during ajax requests too. 
> 
> Is it any way to determine when a request comes from a user that's entered
> an address or followed a link to that page, and make sure that request
> does
> not come from ajax or an action link on it? I think that'd be my
> requirement
> 
> Thanks again, Juan
> -- 
> View this message in context:
> http://old.nabble.com/Good-practices-for-handling-page-cleanup-tp28247499p28247499.html
> Sent from the Tapestry - User mailing list archive at Nabble.com.
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
> 
> 
> 

-- 
View this message in context: http://old.nabble.com/Good-practices-for-handling-page-cleanup-tp28247499p28249538.html
Sent from the Tapestry - User mailing list archive at Nabble.com.


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


RE: Good practices for handling page cleanup

Posted by Alfie Kirkpatrick <Al...@ioko.com>.
There's been some discussion on this in the past. The easiest way if AJAX is your only scenario is probably using request.isXHR(). An alternative is to maybe use the ComponentEventLinkEncoder either directly or by intercepting it. It knows whether the request is for a page or component event.

http://markmail.org/message/mug7wv5gueuw6hhj
http://markmail.org/message/gds72nly2vk5sqm3

Hope it helps,
Alfie.

-----Original Message-----
From: Juan Isern [mailto:juanisern@gmail.com] 
Sent: 14 April 2010 21:01
To: users@tapestry.apache.org
Subject: Good practices for handling page cleanup


Guys, I've been working with some ajax components that need, to work
properly, to store data in the session as persistent fields.

I thought onActivate() would be a nice place to clean things up, doing it at
the very first moment that a page is requested by the user seems ok.

The problem is that onActivate() gets invoked during ajax requests too. 

Is it any way to determine when a request comes from a user that's entered
an address or followed a link to that page, and make sure that request does
not come from ajax or an action link on it? I think that'd be my requirement

Thanks again, Juan
-- 
View this message in context: http://old.nabble.com/Good-practices-for-handling-page-cleanup-tp28247499p28247499.html
Sent from the Tapestry - User mailing list archive at Nabble.com.



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