Ville, Thiago, Thanks for the replies. They well very helpful. ApplicationStateManager works perfectly for my needs.
Regards, Jim. -----Original Message----- From: Ville Virtanen [mailto:ville.virta...@cerion.fi] Sent: 10 January 2010 18:11 To: users@tapestry.apache.org Subject: RE: Advice on Tapestry5 best practise for user session data Hi, as Thiago said you can access the application state using ApplicationStateManager in services, but beware that this approach doesn't work if there is no request. So, you cannot use the service anymore if the calling code is, let's say some sort of batch job that has actually nothing to do with a web request. IMHO web related stuff should never be accessed in low level services / dal to avoid this. If you can live with that restriction it is ok to use ApplicationStateManager. - Ville jc1001 wrote: > > Eric, Juan, > > 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 method call on the service that requires data from it or > is there a way to access it from 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 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, 2010 at 11:34 AM, Erick Erickson > <erickerick...@gmail.com> wrote: >> 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 >> Erick >> >> On Sun, Jan 10, 2010 at 10:58 AM, Jim O'Callaghan >> <j...@peritussolutions.com>wrote: >> >>> I'm trying to work out the best approach to passing a pojo around a > system >>> that is to be used for caching some user relevant data (keys only, and >>> otherwise minimal amounts of information) on a per-user basis. The data > is >>> to be used in a large number of db queries in the system (various > persisted >>> config demarcated by company / division codes) during a user's session, > and >>> as such I don't want to be reloading it from the db on a per-user basis >>> each >>> time. I would like to use a pojo, and do an initial load of the data > when >>> the user logs in (or lazy-load and cache on getter access of specific >>> data), >>> and then have it available around various parts of the system (esp. the >>> service and possibly DAO layer). Can some of you more experienced >>> Tapestry5 >>> users advise on how best to approach this scenario? Is an injected > service >>> containing a map of pojos keyed on user a bad idea? Thanks for any >>> suggestions. >>> >>> Regards, >>> Jim. >>> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > > > -- View this message in context: http://old.nabble.com/Advice-on-Tapestry5-best-practise-for-user-session-data-tp27099574p27100792.html Sent from the Tapestry - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
