commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geoff Longman" <glong...@intelligentworks.com>
Subject Re: [Hivemind] Tapestry/HttpSession service
Date Sun, 07 Mar 2004 02:36:10 GMT
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" <hkrishnaswamy@comcast.net>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Cc: "Tapestry development" <tapestry-dev@jakarta.apache.org>
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: commons-dev-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message