Ahh, but we're trying to reduce our dependency on the Visit. We have many groups of pages, and each group needs to store a distinct set of data. Our visit class was becoming a mess.
Plus, a session local service could also be useful outside of Tapestry where there is no Visit! No reason why a JSP couldn't use a session local service. Geoff ----- Original Message ----- From: "Harish Krishnaswamy" <[EMAIL PROTECTED]> To: "Tapestry development" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Saturday, March 06, 2004 10:14 PM Subject: Re: [Hivemind] Tapestry/HttpSession service > The way I see it, you simply need a regular service with > ThreadLocalStorage. The servlet filter would set the visit in the > ThreadLocalStorage for every request and the service would simply get > and set the data on the visit in the ThreadLocal. Would that work? > > -Harish > > Geoff Longman wrote: > > >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] > > > > > > > > > > --------------------------------------------------------------------- > 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]
