Perhaps, I wish I had more time to read the Hivemind source. I might be getting this wrong but how about a Factory that makes a session local instance of a service? Wait that can't be right. A SessionLocalService that pulls a service from a pool and hooks it up to the session. The existing servlet filter could be a model for a filter that sets up the SessionLocalService with the thread local session.
The above ignores the need to restore/save a service's session local state though. hmm, still thinking.. Geoff ----- Original Message ----- From: "Harish Krishnaswamy" <[EMAIL PROTECTED]> To: "Tapestry development" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Saturday, March 06, 2004 9:54 PM Subject: Re: [Hivemind] Tapestry/HttpSession service > Ah, yes I did miss that part. Seems like you want a wrapper service to > the HttpSession like the Visit? > > Geoff Longman wrote: > > >I don't think ThreadLocalStorage is sufficient. Perhaps this is too specific > >to Tapestry and is a topic for Tapestry 3.1 discussion. > > > >It all boils down to a service that not only is thread local, but is also > >session local. > > > >Geoff > >----- Original Message ----- > >From: "Harish Krishnaswamy" <[EMAIL PROTECTED]> > >To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]> > >Cc: "Tapestry development" <[EMAIL PROTECTED]> > >Sent: Saturday, March 06, 2004 9:28 PM > >Subject: Re: [Hivemind] Tapestry/HttpSession service > > > > > > > > > >>Have you looked into the ThreadLocalStorage? > >> > >>-Harish > >> > >>Geoff Longman wrote: > >> > >> > >> > >>>The content of this message crosses boundaries so I'm cc'ing Tapestry dev > >>>too. > >>> > >>>I have a real problem in a Tapestry application and I'm wondering if > >>> > >>> > >another > > > > > >>>'flavour' of Hivemind service approach would be applicable. > >>> > >>>We have a Tapestry app that has many hundreds of pages. Different groups > >>> > >>> > >of > > > > > >>>pages need to share different sets of information. We have tried using > >>> > >>> > >the > > > > > >>>Visit to share data and have also tried explicity passing things between > >>>pages but both methods are less than ideal.. > >>> > >>>The visit approach ends up being like a big hashtable. Explicity passing > >>>data via method calls leads to coupling between pages. > >>> > >>>What would be nice is a service that is not only pooled, but is peristent > >>> > >>> > >in > > > > > >>>the Tapestry way, i.e. the value of certain fields in the service are > >>>private to one user session. > >>> > >>>An example implementation could be a Wizard that uses 5 pages to build a > >>> > >>> > >new > > > > > >>>customer record in a database. > >>> > >>>If the service I described was doable, each page could access a > >>>NewCustomerWizard service, read data from it and set data in it. The > >>>NewCustomerWizardService could minimally reply to questions like: > >>> > >>>- Can the wizard finish? > >>>- What's the next page to show? > >>>- What's the previous page to show? > >>> > >>>Thus, the pages could interact individually with the service and not be > >>>coupled to one another. > >>> > >>>In fact, a menu component could interrogate the NewCustomerWizardService > >>>also to get the first page to show in order to start the Wizard. Plus, > >>> > >>> > >the > > > > > >>>service could keep track of all the pages used so far and if the user > >>>clicked 'Finish' or 'Cancel', the service could respond with the list of > >>>seen pages for cleanup purposes (forgetPage()). > >>> > >>>Is this wishful thinking? > >>>Cheers, > >>> > >>>Geoff > >>> > >>>Geoffrey Longman > >>>Intelligent Works Inc. > >>> > >>> > >>>--------------------------------------------------------------------- > >>>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] > >> > >> > >> > > > > > >--------------------------------------------------------------------- > >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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
