Re: [Hivemind] Tapestry/HttpSession service

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