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