> 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
<[EMAIL PROTECTED]> 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
> > <[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]
