Re: [Hivemind] Tapestry/HttpSession service

"Geoff Longman" <[email protected]>
Newsgroups gmane.comp.jakarta.tapestry.devel,gmane.text.xml.commons.devel
Message-ID <0d3201c403ec$f3af8cb0$2400a8c0@turbonium>
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]
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.