commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Harish Krishnaswamy <hkrishnasw...@comcast.net>
Subject Re: [Hivemind] Tapestry/HttpSession service
Date Sun, 07 Mar 2004 02:54:18 GMT
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" <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: 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