Re: [Hivemind] Tapestry/HttpSession service

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