You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Stephane Decleire <sd...@cariboo-networks.com> on 2008/04/08 17:11:01 UTC
T5 : session timeout
Hi,
I would like to know how do you handle session timeout with T5 or if
there is a "design pattern" for this case.
When a session timeout occurs, a lot of pages won't work because of a
lack of data (for example, normaly setted before returning the page). So
i need to write a piece of code in the activation event of almost of my
pages. In T4, i would have writen it in a parent page and would have
subclassed all the pages from it. In T5 should i consider writing a
mixin or something else ?
Thanks in advance.
Stephane
Re: T5 : session timeout
Posted by Geoff Callender <ge...@gmail.com>.
Hi Stephane,
I don't think that's a problem - POJOs can be subclasses (after all,
every class is a subclass indirectly of Object). What we're talking
about here is a shared behaviour and it seems to me entirely
appropriate to put the shared behaviour into a superclass.
It's not the only way to solve the problem, but I do see a couple of
other benefits this way:
- it can hold state, which can be handy if, for example, you want to
save the original request while you display a login screen.
- it's very obvious for the maintenance programmer who will follow on
in the years to come!
Cheers,
Geoff
On 12/04/2008, at 7:19 PM, Stephane Decleire wrote:
> Thanks Geoff.
>
> That is the first idea i came up with and i think that it works.
> But Howard has worked hard to let us use any simple POJO as
> pages ;-). Is there any other solution to have a common check on the
> pages activation event without extending a common subclass ?
>
> Stephane
>
> Geoff Callender a écrit :
>> Hi Stephane,
>>
>> No, you are not wrong. A common technique is to put session
>> checking in a common class which all other pages extend. Session
>> checking can be achieved by checking for the existence of an
>> Application State Object that you have set up earlier when
>> something significant happened, eg. when user logged in. Here's an
>> example base class (untested):
>>
>> public class SimpleBasePage {
>>
>> @ApplicationState
>> private Visit _visit;
>> private boolean _visitExists;
>> @InjectPage
>> private Index _index;
>> Object onActivate() {
>>
>> if (!isVisitExists()) {
>> return _index;
>> }
>>
>> return null;
>> }
>>
>> public Visit getVisit() {
>> return _visit;
>> }
>>
>> public boolean isVisitExists() {
>> return _visitExists;
>> }
>> }
>>
>> In this example the _visit can be created simply by calling
>> getVisit(). Tapestry's lazy loading of ASO's does the rest.
>>
>> Make sure you DON'T put your base class in the "pages" package -
>> create a new package, eg. "base".
>>
>> Hope this helps.
>>
>> Geoff
>> http://files.doublenegative.com.au/jumpstart/
>>
>> On 11/04/2008, at 7:57 PM, Stephane Decleire wrote:
>>
>>> I think that i did not explain very well the problem i
>>> encounter ... so i will try to explain it better (so hard in a
>>> foreign language ...)
>>>
>>> Suppose i have a page A which call a page B after initializing a
>>> property of B :
>>>
>>> [Page A]
>>>
>>> @InjectPage
>>> private B b;
>>>
>>> @OnEvent (value="action")
>>> Object gotoB() {
>>> b.setMessage("hello");
>>> return b;
>>> }
>>>
>>> The user is now on the page B with its welcome message. He takes a
>>> break at the coffee machine. When he comes back, he tries to
>>> refresh his page. But he has discuss two much time with his
>>> friends while drinking his coffee and his session has just
>>> expired ! (the session there is the HTTP session).
>>> For Tapestry, that's mean that a new HTTP session will be created
>>> for this user and the page B will be rendered one more time as if
>>> the user was a new one. As a consequence, the content of the
>>> message property will not be set when the page B is rendered.
>>> In this case, it will just be an inconvenient but if the property
>>> is an object and not a string and this object is used in the
>>> rendering of the page B, we will get the awfull "Null pointer
>>> exception" error !!! :-(
>>> Since, the power of Tapestry is to present the developer "HTML
>>> pages" as objects, passing data by setting properties from page to
>>> page is a common pattern and we need to check for the presence of
>>> our properties in allmost all pages of an application when the
>>> HTTP session is lost.
>>> In the simplest case, we need to check the existence of the HTTP
>>> session in allmost all page activation events and redirect the
>>> user on a specific page when the session as expired !
>>> Am i wrong ?
>>>
>>> Stephane
>>>
>>> Josh Canfield a écrit :
>>>>> One approach is to store this data transiently in an ASO.
>>>>>
>>>>
>>>> http://tapestry.apache.org/tapestry5/tapestry-core/guide/appstate.html
>>>>
>>>> "With an ASO, the value is automatically stored outside the page;
>>>> with
>>>> the default storage strategy, it is stored in the session. "
>>>>
>>>> Unless you've built a different ASO storage strategy, your value is
>>>> going into the session and a session timeout will lose that value
>>>> as
>>>> well.
>>>>
>>>> My advice, build your app defensively. Don't depend on objects
>>>> being
>>>> available if they are being pulled from the session, or even the
>>>> database for that matter. Understand what it means if a session
>>>> times
>>>> out at every step of your workflow so you can do the right thing
>>>> when
>>>> the object isn't there. Build tests that hit those pages with no
>>>> session to verify the behavior.
>>>>
>>>> Good luck!
>>>> Josh
>>>>
>>>> On Thu, Apr 10, 2008 at 3:55 AM, Peter Stavrinides
>>>> <p....@albourne.com> wrote:
>>>>
>>>>> Hi Stephane
>>>>>
>>>>> One approach is to store this data transiently in an ASO. (This
>>>>> data object
>>>>> needs to be serializable though, but using soft references works
>>>>> great). In
>>>>> your getter method be sure to check if its null and if so
>>>>> reinitialize
>>>>> it)... Inject the ASO in your pages and never worry about data
>>>>> activation in
>>>>> pages. This is the real value of IoC. However, bear in mind when
>>>>> using
>>>>> persisted data if it becomes large, it gets expensive to carry
>>>>> around in a
>>>>> high volume application, so you loose scalability.
>>>>>
>>>>>
>>>>>
>>>>> Stephane Decleire wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I would like to know how do you handle session timeout with T5
>>>>>> or if there
>>>>>>
>>>>> is a "design pattern" for this case.
>>>>>
>>>>>> When a session timeout occurs, a lot of pages won't work
>>>>>> because of a lack
>>>>>>
>>>>> of data (for example, normaly setted before returning the page).
>>>>> So i need
>>>>> to write a piece of code in the activation event of almost of my
>>>>> pages. In
>>>>> T4, i would have writen it in a parent page and would have
>>>>> subclassed all
>>>>> the pages from it. In T5 should i consider writing a mixin or
>>>>> something else
>>>>> ?
>>>>>
>>>>>> Thanks in advance.
>>>>>>
>>>>>> Stephane
>>>>>>
>>>>>>
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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: T5 : session timeout
Posted by "Filip S. Adamsen" <fs...@fsadev.com>.
Hi,
Yes, there is another solution. Use request filters:
http://www.mail-archive.com/users@tapestry.apache.org/msg21568.html
I use this approach. I check for an annotation on my page class in my
filters and act accordingly.
-Filip
On 2008-04-12 11:19, Stephane Decleire wrote:
> Thanks Geoff.
>
> That is the first idea i came up with and i think that it works.
> But Howard has worked hard to let us use any simple POJO as pages ;-).
> Is there any other solution to have a common check on the pages
> activation event without extending a common subclass ?
>
> Stephane
>
> Geoff Callender a écrit :
>> Hi Stephane,
>>
>> No, you are not wrong. A common technique is to put session checking
>> in a common class which all other pages extend. Session checking can
>> be achieved by checking for the existence of an Application State
>> Object that you have set up earlier when something significant
>> happened, eg. when user logged in. Here's an example base class
>> (untested):
>>
>> public class SimpleBasePage {
>>
>> @ApplicationState
>> private Visit _visit;
>> private boolean _visitExists;
>> @InjectPage
>> private Index _index;
>> Object onActivate() {
>>
>> if (!isVisitExists()) {
>> return _index;
>> }
>>
>> return null;
>> }
>>
>> public Visit getVisit() {
>> return _visit;
>> }
>>
>> public boolean isVisitExists() {
>> return _visitExists;
>> }
>> }
>>
>> In this example the _visit can be created simply by calling
>> getVisit(). Tapestry's lazy loading of ASO's does the rest.
>>
>> Make sure you DON'T put your base class in the "pages" package -
>> create a new package, eg. "base".
>>
>> Hope this helps.
>>
>> Geoff
>> http://files.doublenegative.com.au/jumpstart/
>>
>> On 11/04/2008, at 7:57 PM, Stephane Decleire wrote:
>>
>>> I think that i did not explain very well the problem i encounter ...
>>> so i will try to explain it better (so hard in a foreign language ...)
>>>
>>> Suppose i have a page A which call a page B after initializing a
>>> property of B :
>>>
>>> [Page A]
>>>
>>> @InjectPage
>>> private B b;
>>>
>>> @OnEvent (value="action")
>>> Object gotoB() {
>>> b.setMessage("hello");
>>> return b;
>>> }
>>>
>>> The user is now on the page B with its welcome message. He takes a
>>> break at the coffee machine. When he comes back, he tries to refresh
>>> his page. But he has discuss two much time with his friends while
>>> drinking his coffee and his session has just expired ! (the session
>>> there is the HTTP session).
>>> For Tapestry, that's mean that a new HTTP session will be created for
>>> this user and the page B will be rendered one more time as if the
>>> user was a new one. As a consequence, the content of the message
>>> property will not be set when the page B is rendered.
>>> In this case, it will just be an inconvenient but if the property is
>>> an object and not a string and this object is used in the rendering
>>> of the page B, we will get the awfull "Null pointer exception" error
>>> !!! :-(
>>> Since, the power of Tapestry is to present the developer "HTML pages"
>>> as objects, passing data by setting properties from page to page is a
>>> common pattern and we need to check for the presence of our
>>> properties in allmost all pages of an application when the HTTP
>>> session is lost.
>>> In the simplest case, we need to check the existence of the HTTP
>>> session in allmost all page activation events and redirect the user
>>> on a specific page when the session as expired !
>>> Am i wrong ?
>>>
>>> Stephane
>>>
>>> Josh Canfield a écrit :
>>>>> One approach is to store this data transiently in an ASO.
>>>>>
>>>>
>>>> http://tapestry.apache.org/tapestry5/tapestry-core/guide/appstate.html
>>>>
>>>> "With an ASO, the value is automatically stored outside the page; with
>>>> the default storage strategy, it is stored in the session. "
>>>>
>>>> Unless you've built a different ASO storage strategy, your value is
>>>> going into the session and a session timeout will lose that value as
>>>> well.
>>>>
>>>> My advice, build your app defensively. Don't depend on objects being
>>>> available if they are being pulled from the session, or even the
>>>> database for that matter. Understand what it means if a session times
>>>> out at every step of your workflow so you can do the right thing when
>>>> the object isn't there. Build tests that hit those pages with no
>>>> session to verify the behavior.
>>>>
>>>> Good luck!
>>>> Josh
>>>>
>>>> On Thu, Apr 10, 2008 at 3:55 AM, Peter Stavrinides
>>>> <p....@albourne.com> wrote:
>>>>
>>>>> Hi Stephane
>>>>>
>>>>> One approach is to store this data transiently in an ASO. (This
>>>>> data object
>>>>> needs to be serializable though, but using soft references works
>>>>> great). In
>>>>> your getter method be sure to check if its null and if so reinitialize
>>>>> it)... Inject the ASO in your pages and never worry about data
>>>>> activation in
>>>>> pages. This is the real value of IoC. However, bear in mind when using
>>>>> persisted data if it becomes large, it gets expensive to carry
>>>>> around in a
>>>>> high volume application, so you loose scalability.
>>>>>
>>>>>
>>>>>
>>>>> Stephane Decleire wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I would like to know how do you handle session timeout with T5 or
>>>>>> if there
>>>>>>
>>>>> is a "design pattern" for this case.
>>>>>
>>>>>> When a session timeout occurs, a lot of pages won't work because
>>>>>> of a lack
>>>>>>
>>>>> of data (for example, normaly setted before returning the page). So
>>>>> i need
>>>>> to write a piece of code in the activation event of almost of my
>>>>> pages. In
>>>>> T4, i would have writen it in a parent page and would have
>>>>> subclassed all
>>>>> the pages from it. In T5 should i consider writing a mixin or
>>>>> something else
>>>>> ?
>>>>>
>>>>>> Thanks in advance.
>>>>>>
>>>>>> Stephane
>>>>>>
>>>>>>
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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: T5 : session timeout
Posted by Stephane Decleire <sd...@cariboo-networks.com>.
Thanks Geoff.
That is the first idea i came up with and i think that it works.
But Howard has worked hard to let us use any simple POJO as pages ;-).
Is there any other solution to have a common check on the pages
activation event without extending a common subclass ?
Stephane
Geoff Callender a écrit :
> Hi Stephane,
>
> No, you are not wrong. A common technique is to put session checking
> in a common class which all other pages extend. Session checking can
> be achieved by checking for the existence of an Application State
> Object that you have set up earlier when something significant
> happened, eg. when user logged in. Here's an example base class
> (untested):
>
> public class SimpleBasePage {
>
> @ApplicationState
> private Visit _visit;
> private boolean _visitExists;
>
> @InjectPage
> private Index _index;
>
> Object onActivate() {
>
> if (!isVisitExists()) {
> return _index;
> }
>
> return null;
> }
>
> public Visit getVisit() {
> return _visit;
> }
>
> public boolean isVisitExists() {
> return _visitExists;
> }
> }
>
> In this example the _visit can be created simply by calling
> getVisit(). Tapestry's lazy loading of ASO's does the rest.
>
> Make sure you DON'T put your base class in the "pages" package -
> create a new package, eg. "base".
>
> Hope this helps.
>
> Geoff
> http://files.doublenegative.com.au/jumpstart/
>
> On 11/04/2008, at 7:57 PM, Stephane Decleire wrote:
>
>> I think that i did not explain very well the problem i encounter ...
>> so i will try to explain it better (so hard in a foreign language ...)
>>
>> Suppose i have a page A which call a page B after initializing a
>> property of B :
>>
>> [Page A]
>>
>> @InjectPage
>> private B b;
>>
>> @OnEvent (value="action")
>> Object gotoB() {
>> b.setMessage("hello");
>> return b;
>> }
>>
>> The user is now on the page B with its welcome message. He takes a
>> break at the coffee machine. When he comes back, he tries to refresh
>> his page. But he has discuss two much time with his friends while
>> drinking his coffee and his session has just expired ! (the session
>> there is the HTTP session).
>> For Tapestry, that's mean that a new HTTP session will be created for
>> this user and the page B will be rendered one more time as if the
>> user was a new one. As a consequence, the content of the message
>> property will not be set when the page B is rendered.
>> In this case, it will just be an inconvenient but if the property is
>> an object and not a string and this object is used in the rendering
>> of the page B, we will get the awfull "Null pointer exception" error
>> !!! :-(
>> Since, the power of Tapestry is to present the developer "HTML pages"
>> as objects, passing data by setting properties from page to page is a
>> common pattern and we need to check for the presence of our
>> properties in allmost all pages of an application when the HTTP
>> session is lost.
>> In the simplest case, we need to check the existence of the HTTP
>> session in allmost all page activation events and redirect the user
>> on a specific page when the session as expired !
>> Am i wrong ?
>>
>> Stephane
>>
>> Josh Canfield a écrit :
>>>> One approach is to store this data transiently in an ASO.
>>>>
>>>
>>> http://tapestry.apache.org/tapestry5/tapestry-core/guide/appstate.html
>>>
>>> "With an ASO, the value is automatically stored outside the page; with
>>> the default storage strategy, it is stored in the session. "
>>>
>>> Unless you've built a different ASO storage strategy, your value is
>>> going into the session and a session timeout will lose that value as
>>> well.
>>>
>>> My advice, build your app defensively. Don't depend on objects being
>>> available if they are being pulled from the session, or even the
>>> database for that matter. Understand what it means if a session times
>>> out at every step of your workflow so you can do the right thing when
>>> the object isn't there. Build tests that hit those pages with no
>>> session to verify the behavior.
>>>
>>> Good luck!
>>> Josh
>>>
>>> On Thu, Apr 10, 2008 at 3:55 AM, Peter Stavrinides
>>> <p....@albourne.com> wrote:
>>>
>>>> Hi Stephane
>>>>
>>>> One approach is to store this data transiently in an ASO. (This
>>>> data object
>>>> needs to be serializable though, but using soft references works
>>>> great). In
>>>> your getter method be sure to check if its null and if so reinitialize
>>>> it)... Inject the ASO in your pages and never worry about data
>>>> activation in
>>>> pages. This is the real value of IoC. However, bear in mind when using
>>>> persisted data if it becomes large, it gets expensive to carry
>>>> around in a
>>>> high volume application, so you loose scalability.
>>>>
>>>>
>>>>
>>>> Stephane Decleire wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I would like to know how do you handle session timeout with T5 or
>>>>> if there
>>>>>
>>>> is a "design pattern" for this case.
>>>>
>>>>> When a session timeout occurs, a lot of pages won't work because
>>>>> of a lack
>>>>>
>>>> of data (for example, normaly setted before returning the page). So
>>>> i need
>>>> to write a piece of code in the activation event of almost of my
>>>> pages. In
>>>> T4, i would have writen it in a parent page and would have
>>>> subclassed all
>>>> the pages from it. In T5 should i consider writing a mixin or
>>>> something else
>>>> ?
>>>>
>>>>> Thanks in advance.
>>>>>
>>>>> Stephane
>>>>>
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>
>
Re: T5 : session timeout
Posted by Geoff Callender <ge...@gmail.com>.
Hi Stephane,
No, you are not wrong. A common technique is to put session checking
in a common class which all other pages extend. Session checking can
be achieved by checking for the existence of an Application State
Object that you have set up earlier when something significant
happened, eg. when user logged in. Here's an example base class
(untested):
public class SimpleBasePage {
@ApplicationState
private Visit _visit;
private boolean _visitExists;
@InjectPage
private Index _index;
Object onActivate() {
if (!isVisitExists()) {
return _index;
}
return null;
}
public Visit getVisit() {
return _visit;
}
public boolean isVisitExists() {
return _visitExists;
}
}
In this example the _visit can be created simply by calling
getVisit(). Tapestry's lazy loading of ASO's does the rest.
Make sure you DON'T put your base class in the "pages" package -
create a new package, eg. "base".
Hope this helps.
Geoff
http://files.doublenegative.com.au/jumpstart/
On 11/04/2008, at 7:57 PM, Stephane Decleire wrote:
> I think that i did not explain very well the problem i encounter ...
> so i will try to explain it better (so hard in a foreign language ...)
>
> Suppose i have a page A which call a page B after initializing a
> property of B :
>
> [Page A]
>
> @InjectPage
> private B b;
>
> @OnEvent (value="action")
> Object gotoB() {
> b.setMessage("hello");
> return b;
> }
>
> The user is now on the page B with its welcome message. He takes a
> break at the coffee machine. When he comes back, he tries to refresh
> his page. But he has discuss two much time with his friends while
> drinking his coffee and his session has just expired ! (the session
> there is the HTTP session).
> For Tapestry, that's mean that a new HTTP session will be created
> for this user and the page B will be rendered one more time as if
> the user was a new one. As a consequence, the content of the message
> property will not be set when the page B is rendered.
> In this case, it will just be an inconvenient but if the property is
> an object and not a string and this object is used in the rendering
> of the page B, we will get the awfull "Null pointer exception"
> error !!! :-(
> Since, the power of Tapestry is to present the developer "HTML
> pages" as objects, passing data by setting properties from page to
> page is a common pattern and we need to check for the presence of
> our properties in allmost all pages of an application when the HTTP
> session is lost.
> In the simplest case, we need to check the existence of the HTTP
> session in allmost all page activation events and redirect the user
> on a specific page when the session as expired !
> Am i wrong ?
>
> Stephane
>
> Josh Canfield a écrit :
>>> One approach is to store this data transiently in an ASO.
>>>
>>
>> http://tapestry.apache.org/tapestry5/tapestry-core/guide/
>> appstate.html
>>
>> "With an ASO, the value is automatically stored outside the page;
>> with
>> the default storage strategy, it is stored in the session. "
>>
>> Unless you've built a different ASO storage strategy, your value is
>> going into the session and a session timeout will lose that value as
>> well.
>>
>> My advice, build your app defensively. Don't depend on objects being
>> available if they are being pulled from the session, or even the
>> database for that matter. Understand what it means if a session times
>> out at every step of your workflow so you can do the right thing when
>> the object isn't there. Build tests that hit those pages with no
>> session to verify the behavior.
>>
>> Good luck!
>> Josh
>>
>> On Thu, Apr 10, 2008 at 3:55 AM, Peter Stavrinides
>> <p....@albourne.com> wrote:
>>
>>> Hi Stephane
>>>
>>> One approach is to store this data transiently in an ASO. (This
>>> data object
>>> needs to be serializable though, but using soft references works
>>> great). In
>>> your getter method be sure to check if its null and if so
>>> reinitialize
>>> it)... Inject the ASO in your pages and never worry about data
>>> activation in
>>> pages. This is the real value of IoC. However, bear in mind when
>>> using
>>> persisted data if it becomes large, it gets expensive to carry
>>> around in a
>>> high volume application, so you loose scalability.
>>>
>>>
>>>
>>> Stephane Decleire wrote:
>>>
>>>> Hi,
>>>>
>>>> I would like to know how do you handle session timeout with T5 or
>>>> if there
>>>>
>>> is a "design pattern" for this case.
>>>
>>>> When a session timeout occurs, a lot of pages won't work because
>>>> of a lack
>>>>
>>> of data (for example, normaly setted before returning the page).
>>> So i need
>>> to write a piece of code in the activation event of almost of my
>>> pages. In
>>> T4, i would have writen it in a parent page and would have
>>> subclassed all
>>> the pages from it. In T5 should i consider writing a mixin or
>>> something else
>>> ?
>>>
>>>> Thanks in advance.
>>>>
>>>> Stephane
>>>>
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>>>
>>>
>>
>>
>>
>>
Re: T5 : session timeout
Posted by Josh Canfield <jo...@thedailytube.com>.
> I think that your solution is the best but also the hardest way ! Checking
> every properties in every pages ... wooahh !
:) Hehehe... yeah, I tend to lean towards correct over easy.
On Sat, Apr 12, 2008 at 2:24 AM, Stephane Decleire
<sd...@cariboo-networks.com> wrote:
> Thanks Josh,
>
> I think that your solution is the best but also the hardest way ! Checking
> every properties in every pages ... wooahh !
> Would not it be very handy to have the framework raise an event in case of
> a session loss (for example as for a 404 error) that we could catch to
> simply redirect to a specific page or to further investigate and check
> properties like in your solution for specific pages ?
>
>
>
> Stephane
>
> Josh Canfield a écrit :
>
> > Hey Stephane,
> >
> >
> >
> > > I think that i did not explain very well the problem i encounter ... so
> i
> > > will try to explain it better (so hard in a foreign language ...)
> > >
> > >
> >
> > I understood the problem, sorry if my answer didn't give you what you
> needed :)
> >
> >
> >
> > > In this case, it will just be an inconvenient but if the property is an
> > > object and not a string and this object is used in the rendering of the
> page
> > > B, we will get the awfull "Null pointer exception" error !!! :-(
> > >
> > >
> >
> > The basic pattern would be to check your state in one of your
> > onActivate methods and redirect or proceed based on your requirements.
> > activation events are called in order of name, then number of
> > properties so you can pick whether your activation happens before or
> > after your general activation occurs.
> >
> > @OnEvent("activate")
> > public Object _onActivate() {
> > // to run before other activation handlers
> > // check @Persist properties
> > }
> >
> > If this is a common property between a set of pages then you can
> > consider creating a base class with it's own activation handler to
> > consolidate your property validation. If the property is invalid
> > (null, incomplete, etc) you can do the right thing for your pages
> > whether that is redirecting to another page, initialize the object
> > somehow or something else. In some cases, like message, do nothing is
> > probably an ok answer.
> >
> >
> >
> > > In the simplest case, we need to check the existence of the HTTP session
> in
> > > allmost all page activation events and redirect the user on a specific
> page
> > > when the session as expired !
> > >
> > >
> >
> > I wouldn't check for the existence of the HTTP session, I'd actually
> > validate the individual properties in the page. This is what I mean by
> > programming defensively. You can't infer that if a session exists, or
> > even that one of your properties is set, that all of your properties
> > are safe, who knows how your user got to the page, or how your
> > co-worker wrote his page that is linking to yours.
> >
> > Josh
> >
> > On Fri, Apr 11, 2008 at 2:57 AM, Stephane Decleire
> > <sd...@cariboo-networks.com> wrote:
> >
> >
> > > I think that i did not explain very well the problem i encounter ... so
> i
> > > will try to explain it better (so hard in a foreign language ...)
> > >
> > > Suppose i have a page A which call a page B after initializing a
> property of
> > > B :
> > >
> > > [Page A]
> > >
> > > @InjectPage
> > > private B b;
> > >
> > > @OnEvent (value="action")
> > > Object gotoB() {
> > > b.setMessage("hello");
> > > return b;
> > > }
> > >
> > > The user is now on the page B with its welcome message. He takes a break
> at
> > > the coffee machine. When he comes back, he tries to refresh his page.
> But he
> > > has discuss two much time with his friends while drinking his coffee and
> his
> > > session has just expired ! (the session there is the HTTP session).
> > > For Tapestry, that's mean that a new HTTP session will be created for
> this
> > > user and the page B will be rendered one more time as if the user was a
> new
> > > one. As a consequence, the content of the message property will not be
> set
> > > when the page B is rendered.
> > > In this case, it will just be an inconvenient but if the property is an
> > > object and not a string and this object is used in the rendering of the
> page
> > > B, we will get the awfull "Null pointer exception" error !!! :-(
> > > Since, the power of Tapestry is to present the developer "HTML pages" as
> > > objects, passing data by setting properties from page to page is a
> common
> > > pattern and we need to check for the presence of our properties in
> allmost
> > > all pages of an application when the HTTP session is lost.
> > > In the simplest case, we need to check the existence of the HTTP session
> in
> > > allmost all page activation events and redirect the user on a specific
> page
> > > when the session as expired !
> > > Am i wrong ?
> > >
> > > Stephane
> > >
> > > Josh Canfield a écrit :
> > >
> > >
> > >
> > >
> > > >
> > > > > One approach is to store this data transiently in an ASO.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > http://tapestry.apache.org/tapestry5/tapestry-core/guide/appstate.html
> > > >
> > > > "With an ASO, the value is automatically stored outside the page; with
> > > > the default storage strategy, it is stored in the session. "
> > > >
> > > > Unless you've built a different ASO storage strategy, your value is
> > > > going into the session and a session timeout will lose that value as
> > > > well.
> > > >
> > > > My advice, build your app defensively. Don't depend on objects being
> > > > available if they are being pulled from the session, or even the
> > > > database for that matter. Understand what it means if a session times
> > > > out at every step of your workflow so you can do the right thing when
> > > > the object isn't there. Build tests that hit those pages with no
> > > > session to verify the behavior.
> > > >
> > > > Good luck!
> > > > Josh
> > > >
> > > > On Thu, Apr 10, 2008 at 3:55 AM, Peter Stavrinides
> > > > <p....@albourne.com> wrote:
> > > >
> > > >
> > > >
> > > >
> > > > > Hi Stephane
> > > > >
> > > > > One approach is to store this data transiently in an ASO. (This data
> > > > >
> > > > >
> > > >
> > > object
> > >
> > >
> > > >
> > > > > needs to be serializable though, but using soft references works
> great).
> > > > >
> > > > >
> > > >
> > > In
> > >
> > >
> > > >
> > > > > your getter method be sure to check if its null and if so
> reinitialize
> > > > > it)... Inject the ASO in your pages and never worry about data
> > > > >
> > > > >
> > > >
> > > activation in
> > >
> > >
> > > >
> > > > > pages. This is the real value of IoC. However, bear in mind when
> using
> > > > > persisted data if it becomes large, it gets expensive to carry
> around in
> > > > >
> > > > >
> > > >
> > > a
> > >
> > >
> > > >
> > > > > high volume application, so you loose scalability.
> > > > >
> > > > >
> > > > >
> > > > > Stephane Decleire wrote:
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > > Hi,
> > > > > >
> > > > > > I would like to know how do you handle session timeout with T5 or
> if
> > > > > >
> > > > > >
> > > > >
> > > >
> > > there
> > >
> > >
> > > >
> > > > >
> > > > > >
> > > > > >
> > > > > is a "design pattern" for this case.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > > When a session timeout occurs, a lot of pages won't work because
> of a
> > > > > >
> > > > > >
> > > > >
> > > >
> > > lack
> > >
> > >
> > > >
> > > > >
> > > > > >
> > > > > >
> > > > > of data (for example, normaly setted before returning the page). So
> i
> > > > >
> > > > >
> > > >
> > > need
> > >
> > >
> > > >
> > > > > to write a piece of code in the activation event of almost of my
> pages.
> > > > >
> > > > >
> > > >
> > > In
> > >
> > >
> > > >
> > > > > T4, i would have writen it in a parent page and would have
> subclassed
> > > > >
> > > > >
> > > >
> > > all
> > >
> > >
> > > >
> > > > > the pages from it. In T5 should i consider writing a mixin or
> something
> > > > >
> > > > >
> > > >
> > > else
> > >
> > >
> > > >
> > > > > ?
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > > Thanks in advance.
> > > > > >
> > > > > > Stephane
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > > > > For additional commands, e-mail: users-help@tapestry.apache.org
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> >
> >
> >
> >
> >
>
--
--
TheDailyTube.com. Sign up and get the best new videos on the internet
delivered fresh to your inbox.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5 : session timeout
Posted by Stephane Decleire <sd...@cariboo-networks.com>.
Thanks Josh,
I think that your solution is the best but also the hardest way !
Checking every properties in every pages ... wooahh !
Would not it be very handy to have the framework raise an event in case
of a session loss (for example as for a 404 error) that we could catch
to simply redirect to a specific page or to further investigate and
check properties like in your solution for specific pages ?
Stephane
Josh Canfield a écrit :
> Hey Stephane,
>
>
>> I think that i did not explain very well the problem i encounter ... so i
>> will try to explain it better (so hard in a foreign language ...)
>>
>
> I understood the problem, sorry if my answer didn't give you what you needed :)
>
>
>> In this case, it will just be an inconvenient but if the property is an
>> object and not a string and this object is used in the rendering of the page
>> B, we will get the awfull "Null pointer exception" error !!! :-(
>>
>
> The basic pattern would be to check your state in one of your
> onActivate methods and redirect or proceed based on your requirements.
> activation events are called in order of name, then number of
> properties so you can pick whether your activation happens before or
> after your general activation occurs.
>
> @OnEvent("activate")
> public Object _onActivate() {
> // to run before other activation handlers
> // check @Persist properties
> }
>
> If this is a common property between a set of pages then you can
> consider creating a base class with it's own activation handler to
> consolidate your property validation. If the property is invalid
> (null, incomplete, etc) you can do the right thing for your pages
> whether that is redirecting to another page, initialize the object
> somehow or something else. In some cases, like message, do nothing is
> probably an ok answer.
>
>
>> In the simplest case, we need to check the existence of the HTTP session in
>> allmost all page activation events and redirect the user on a specific page
>> when the session as expired !
>>
>
> I wouldn't check for the existence of the HTTP session, I'd actually
> validate the individual properties in the page. This is what I mean by
> programming defensively. You can't infer that if a session exists, or
> even that one of your properties is set, that all of your properties
> are safe, who knows how your user got to the page, or how your
> co-worker wrote his page that is linking to yours.
>
> Josh
>
> On Fri, Apr 11, 2008 at 2:57 AM, Stephane Decleire
> <sd...@cariboo-networks.com> wrote:
>
>> I think that i did not explain very well the problem i encounter ... so i
>> will try to explain it better (so hard in a foreign language ...)
>>
>> Suppose i have a page A which call a page B after initializing a property of
>> B :
>>
>> [Page A]
>>
>> @InjectPage
>> private B b;
>>
>> @OnEvent (value="action")
>> Object gotoB() {
>> b.setMessage("hello");
>> return b;
>> }
>>
>> The user is now on the page B with its welcome message. He takes a break at
>> the coffee machine. When he comes back, he tries to refresh his page. But he
>> has discuss two much time with his friends while drinking his coffee and his
>> session has just expired ! (the session there is the HTTP session).
>> For Tapestry, that's mean that a new HTTP session will be created for this
>> user and the page B will be rendered one more time as if the user was a new
>> one. As a consequence, the content of the message property will not be set
>> when the page B is rendered.
>> In this case, it will just be an inconvenient but if the property is an
>> object and not a string and this object is used in the rendering of the page
>> B, we will get the awfull "Null pointer exception" error !!! :-(
>> Since, the power of Tapestry is to present the developer "HTML pages" as
>> objects, passing data by setting properties from page to page is a common
>> pattern and we need to check for the presence of our properties in allmost
>> all pages of an application when the HTTP session is lost.
>> In the simplest case, we need to check the existence of the HTTP session in
>> allmost all page activation events and redirect the user on a specific page
>> when the session as expired !
>> Am i wrong ?
>>
>> Stephane
>>
>> Josh Canfield a écrit :
>>
>>
>>
>>>> One approach is to store this data transiently in an ASO.
>>>>
>>>>
>>>>
>>> http://tapestry.apache.org/tapestry5/tapestry-core/guide/appstate.html
>>>
>>> "With an ASO, the value is automatically stored outside the page; with
>>> the default storage strategy, it is stored in the session. "
>>>
>>> Unless you've built a different ASO storage strategy, your value is
>>> going into the session and a session timeout will lose that value as
>>> well.
>>>
>>> My advice, build your app defensively. Don't depend on objects being
>>> available if they are being pulled from the session, or even the
>>> database for that matter. Understand what it means if a session times
>>> out at every step of your workflow so you can do the right thing when
>>> the object isn't there. Build tests that hit those pages with no
>>> session to verify the behavior.
>>>
>>> Good luck!
>>> Josh
>>>
>>> On Thu, Apr 10, 2008 at 3:55 AM, Peter Stavrinides
>>> <p....@albourne.com> wrote:
>>>
>>>
>>>
>>>> Hi Stephane
>>>>
>>>> One approach is to store this data transiently in an ASO. (This data
>>>>
>> object
>>
>>>> needs to be serializable though, but using soft references works great).
>>>>
>> In
>>
>>>> your getter method be sure to check if its null and if so reinitialize
>>>> it)... Inject the ASO in your pages and never worry about data
>>>>
>> activation in
>>
>>>> pages. This is the real value of IoC. However, bear in mind when using
>>>> persisted data if it becomes large, it gets expensive to carry around in
>>>>
>> a
>>
>>>> high volume application, so you loose scalability.
>>>>
>>>>
>>>>
>>>> Stephane Decleire wrote:
>>>>
>>>>
>>>>
>>>>> Hi,
>>>>>
>>>>> I would like to know how do you handle session timeout with T5 or if
>>>>>
>> there
>>
>>>>>
>>>> is a "design pattern" for this case.
>>>>
>>>>
>>>>
>>>>> When a session timeout occurs, a lot of pages won't work because of a
>>>>>
>> lack
>>
>>>>>
>>>> of data (for example, normaly setted before returning the page). So i
>>>>
>> need
>>
>>>> to write a piece of code in the activation event of almost of my pages.
>>>>
>> In
>>
>>>> T4, i would have writen it in a parent page and would have subclassed
>>>>
>> all
>>
>>>> the pages from it. In T5 should i consider writing a mixin or something
>>>>
>> else
>>
>>>> ?
>>>>
>>>>
>>>>
>>>>> Thanks in advance.
>>>>>
>>>>> Stephane
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>
>
>
>
Re: T5 : session timeout
Posted by Josh Canfield <jo...@thedailytube.com>.
Hey Stephane,
> I think that i did not explain very well the problem i encounter ... so i
> will try to explain it better (so hard in a foreign language ...)
I understood the problem, sorry if my answer didn't give you what you needed :)
> In this case, it will just be an inconvenient but if the property is an
> object and not a string and this object is used in the rendering of the page
> B, we will get the awfull "Null pointer exception" error !!! :-(
The basic pattern would be to check your state in one of your
onActivate methods and redirect or proceed based on your requirements.
activation events are called in order of name, then number of
properties so you can pick whether your activation happens before or
after your general activation occurs.
@OnEvent("activate")
public Object _onActivate() {
// to run before other activation handlers
// check @Persist properties
}
If this is a common property between a set of pages then you can
consider creating a base class with it's own activation handler to
consolidate your property validation. If the property is invalid
(null, incomplete, etc) you can do the right thing for your pages
whether that is redirecting to another page, initialize the object
somehow or something else. In some cases, like message, do nothing is
probably an ok answer.
> In the simplest case, we need to check the existence of the HTTP session in
> allmost all page activation events and redirect the user on a specific page
> when the session as expired !
I wouldn't check for the existence of the HTTP session, I'd actually
validate the individual properties in the page. This is what I mean by
programming defensively. You can't infer that if a session exists, or
even that one of your properties is set, that all of your properties
are safe, who knows how your user got to the page, or how your
co-worker wrote his page that is linking to yours.
Josh
On Fri, Apr 11, 2008 at 2:57 AM, Stephane Decleire
<sd...@cariboo-networks.com> wrote:
> I think that i did not explain very well the problem i encounter ... so i
> will try to explain it better (so hard in a foreign language ...)
>
> Suppose i have a page A which call a page B after initializing a property of
> B :
>
> [Page A]
>
> @InjectPage
> private B b;
>
> @OnEvent (value="action")
> Object gotoB() {
> b.setMessage("hello");
> return b;
> }
>
> The user is now on the page B with its welcome message. He takes a break at
> the coffee machine. When he comes back, he tries to refresh his page. But he
> has discuss two much time with his friends while drinking his coffee and his
> session has just expired ! (the session there is the HTTP session).
> For Tapestry, that's mean that a new HTTP session will be created for this
> user and the page B will be rendered one more time as if the user was a new
> one. As a consequence, the content of the message property will not be set
> when the page B is rendered.
> In this case, it will just be an inconvenient but if the property is an
> object and not a string and this object is used in the rendering of the page
> B, we will get the awfull "Null pointer exception" error !!! :-(
> Since, the power of Tapestry is to present the developer "HTML pages" as
> objects, passing data by setting properties from page to page is a common
> pattern and we need to check for the presence of our properties in allmost
> all pages of an application when the HTTP session is lost.
> In the simplest case, we need to check the existence of the HTTP session in
> allmost all page activation events and redirect the user on a specific page
> when the session as expired !
> Am i wrong ?
>
> Stephane
>
> Josh Canfield a écrit :
>
>
> >
> > > One approach is to store this data transiently in an ASO.
> > >
> > >
> >
> > http://tapestry.apache.org/tapestry5/tapestry-core/guide/appstate.html
> >
> > "With an ASO, the value is automatically stored outside the page; with
> > the default storage strategy, it is stored in the session. "
> >
> > Unless you've built a different ASO storage strategy, your value is
> > going into the session and a session timeout will lose that value as
> > well.
> >
> > My advice, build your app defensively. Don't depend on objects being
> > available if they are being pulled from the session, or even the
> > database for that matter. Understand what it means if a session times
> > out at every step of your workflow so you can do the right thing when
> > the object isn't there. Build tests that hit those pages with no
> > session to verify the behavior.
> >
> > Good luck!
> > Josh
> >
> > On Thu, Apr 10, 2008 at 3:55 AM, Peter Stavrinides
> > <p....@albourne.com> wrote:
> >
> >
> > > Hi Stephane
> > >
> > > One approach is to store this data transiently in an ASO. (This data
> object
> > > needs to be serializable though, but using soft references works great).
> In
> > > your getter method be sure to check if its null and if so reinitialize
> > > it)... Inject the ASO in your pages and never worry about data
> activation in
> > > pages. This is the real value of IoC. However, bear in mind when using
> > > persisted data if it becomes large, it gets expensive to carry around in
> a
> > > high volume application, so you loose scalability.
> > >
> > >
> > >
> > > Stephane Decleire wrote:
> > >
> > >
> > > > Hi,
> > > >
> > > > I would like to know how do you handle session timeout with T5 or if
> there
> > > >
> > > >
> > > is a "design pattern" for this case.
> > >
> > >
> > > > When a session timeout occurs, a lot of pages won't work because of a
> lack
> > > >
> > > >
> > > of data (for example, normaly setted before returning the page). So i
> need
> > > to write a piece of code in the activation event of almost of my pages.
> In
> > > T4, i would have writen it in a parent page and would have subclassed
> all
> > > the pages from it. In T5 should i consider writing a mixin or something
> else
> > > ?
> > >
> > >
> > > > Thanks in advance.
> > > >
> > > > Stephane
> > > >
> > > >
> > > >
> > > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > > For additional commands, e-mail: users-help@tapestry.apache.org
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> >
>
--
--
TheDailyTube.com. Sign up and get the best new videos on the internet
delivered fresh to your inbox.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5 : session timeout
Posted by Stephane Decleire <sd...@cariboo-networks.com>.
I think that i did not explain very well the problem i encounter ... so
i will try to explain it better (so hard in a foreign language ...)
Suppose i have a page A which call a page B after initializing a
property of B :
[Page A]
@InjectPage
private B b;
@OnEvent (value="action")
Object gotoB() {
b.setMessage("hello");
return b;
}
The user is now on the page B with its welcome message. He takes a break
at the coffee machine. When he comes back, he tries to refresh his page.
But he has discuss two much time with his friends while drinking his
coffee and his session has just expired ! (the session there is the HTTP
session).
For Tapestry, that's mean that a new HTTP session will be created for
this user and the page B will be rendered one more time as if the user
was a new one. As a consequence, the content of the message property
will not be set when the page B is rendered.
In this case, it will just be an inconvenient but if the property is an
object and not a string and this object is used in the rendering of the
page B, we will get the awfull "Null pointer exception" error !!! :-(
Since, the power of Tapestry is to present the developer "HTML pages" as
objects, passing data by setting properties from page to page is a
common pattern and we need to check for the presence of our properties
in allmost all pages of an application when the HTTP session is lost.
In the simplest case, we need to check the existence of the HTTP session
in allmost all page activation events and redirect the user on a
specific page when the session as expired !
Am i wrong ?
Stephane
Josh Canfield a écrit :
>> One approach is to store this data transiently in an ASO.
>>
>
> http://tapestry.apache.org/tapestry5/tapestry-core/guide/appstate.html
>
> "With an ASO, the value is automatically stored outside the page; with
> the default storage strategy, it is stored in the session. "
>
> Unless you've built a different ASO storage strategy, your value is
> going into the session and a session timeout will lose that value as
> well.
>
> My advice, build your app defensively. Don't depend on objects being
> available if they are being pulled from the session, or even the
> database for that matter. Understand what it means if a session times
> out at every step of your workflow so you can do the right thing when
> the object isn't there. Build tests that hit those pages with no
> session to verify the behavior.
>
> Good luck!
> Josh
>
> On Thu, Apr 10, 2008 at 3:55 AM, Peter Stavrinides
> <p....@albourne.com> wrote:
>
>> Hi Stephane
>>
>> One approach is to store this data transiently in an ASO. (This data object
>> needs to be serializable though, but using soft references works great). In
>> your getter method be sure to check if its null and if so reinitialize
>> it)... Inject the ASO in your pages and never worry about data activation in
>> pages. This is the real value of IoC. However, bear in mind when using
>> persisted data if it becomes large, it gets expensive to carry around in a
>> high volume application, so you loose scalability.
>>
>>
>>
>> Stephane Decleire wrote:
>>
>>> Hi,
>>>
>>> I would like to know how do you handle session timeout with T5 or if there
>>>
>> is a "design pattern" for this case.
>>
>>> When a session timeout occurs, a lot of pages won't work because of a lack
>>>
>> of data (for example, normaly setted before returning the page). So i need
>> to write a piece of code in the activation event of almost of my pages. In
>> T4, i would have writen it in a parent page and would have subclassed all
>> the pages from it. In T5 should i consider writing a mixin or something else
>> ?
>>
>>> Thanks in advance.
>>>
>>> Stephane
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>>
>
>
>
>
Re: T5 : session timeout
Posted by Josh Canfield <jo...@thedailytube.com>.
> One approach is to store this data transiently in an ASO.
http://tapestry.apache.org/tapestry5/tapestry-core/guide/appstate.html
"With an ASO, the value is automatically stored outside the page; with
the default storage strategy, it is stored in the session. "
Unless you've built a different ASO storage strategy, your value is
going into the session and a session timeout will lose that value as
well.
My advice, build your app defensively. Don't depend on objects being
available if they are being pulled from the session, or even the
database for that matter. Understand what it means if a session times
out at every step of your workflow so you can do the right thing when
the object isn't there. Build tests that hit those pages with no
session to verify the behavior.
Good luck!
Josh
On Thu, Apr 10, 2008 at 3:55 AM, Peter Stavrinides
<p....@albourne.com> wrote:
> Hi Stephane
>
> One approach is to store this data transiently in an ASO. (This data object
> needs to be serializable though, but using soft references works great). In
> your getter method be sure to check if its null and if so reinitialize
> it)... Inject the ASO in your pages and never worry about data activation in
> pages. This is the real value of IoC. However, bear in mind when using
> persisted data if it becomes large, it gets expensive to carry around in a
> high volume application, so you loose scalability.
>
>
>
> Stephane Decleire wrote:
> > Hi,
> >
> > I would like to know how do you handle session timeout with T5 or if there
> is a "design pattern" for this case.
> > When a session timeout occurs, a lot of pages won't work because of a lack
> of data (for example, normaly setted before returning the page). So i need
> to write a piece of code in the activation event of almost of my pages. In
> T4, i would have writen it in a parent page and would have subclassed all
> the pages from it. In T5 should i consider writing a mixin or something else
> ?
> >
> > Thanks in advance.
> >
> > Stephane
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
--
TheDailyTube.com. Sign up and get the best new videos on the internet
delivered fresh to your inbox.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5 : session timeout
Posted by Peter Stavrinides <p....@albourne.com>.
Hi Stephane
One approach is to store this data transiently in an ASO. (This data
object needs to be serializable though, but using soft references works
great). In your getter method be sure to check if its null and if so
reinitialize it)... Inject the ASO in your pages and never worry about
data activation in pages. This is the real value of IoC. However, bear
in mind when using persisted data if it becomes large, it gets expensive
to carry around in a high volume application, so you loose scalability.
Stephane Decleire wrote:
> Hi,
>
> I would like to know how do you handle session timeout with T5 or if
> there is a "design pattern" for this case.
> When a session timeout occurs, a lot of pages won't work because of a
> lack of data (for example, normaly setted before returning the page).
> So i need to write a piece of code in the activation event of almost
> of my pages. In T4, i would have writen it in a parent page and would
> have subclassed all the pages from it. In T5 should i consider writing
> a mixin or something else ?
>
> Thanks in advance.
>
> Stephane
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org