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
<[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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
