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
<[EMAIL PROTECTED]> 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
> > <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> >
>
--
--
TheDailyTube.com. Sign up and get the best new videos on the internet
delivered fresh to your inbox.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
