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]
