gt; Sent: 10 January 2010 16:47
> To: Tapestry users
> Subject: Re: Advice on Tapestry5 best practise for user session data
>
>
> I would also use a @SessionState pojo. The approach of the service
> having a map wouldn't work in a clustered environment.
>
> On Sun, Jan 10, 2
om a service? As you can probably guess,
> I'm
> trying to minimise interface / method signature changes? Thanks.
>
> Regards,
> Jim.
>
> -Original Message-
> From: Juan E. Maya [mailto:maya.j...@gmail.com]
> Sent: 10 January 2010 16:47
> To: Tapestry us
Em Sun, 10 Jan 2010 15:09:30 -0200, Jim O'Callaghan
escreveu:
Thanks for the replies. I can see how this would work between
pages/components but how would it work say from a service that was used
as some sort of entity manager? Would it be a question of passing it as
a
parameter to each
I would follow this guide:
http://tapestry.apache.org/tapestry5/guide/appstate.html
and make my own app state object, UserSession, which would contain the
needed per user data. (The keys anyway.) There can be services that provide
data based on these keys, and those services should also take care
dvice on Tapestry5 best practise for user session data
I would also use a @SessionState pojo. The approach of the service
having a map wouldn't work in a clustered environment.
On Sun, Jan 10, 2010 at 11:34 AM, Erick Erickson
wrote:
> POJOs can be stored as @SessionState variables
I would also use a @SessionState pojo. The approach of the service
having a map wouldn't work in a clustered environment.
On Sun, Jan 10, 2010 at 11:34 AM, Erick Erickson
wrote:
> POJOs can be stored as @SessionState variables *if* they're
> serializable (as I understand it), would that work?
>
>
POJOs can be stored as @SessionState variables *if* they're
serializable (as I understand it), would that work?
I can't weigh in on the pros and cons of memory usage etc over
your injected service idea, but using @SessionState would
be simpler code-wise until you had reason to change
FWIW
Eri
