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 03:14:17 GMT
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" <hkrishnaswamy@comcast.net>
>To: "Tapestry development" <tapestry-dev@jakarta.apache.org>;
><commons-dev@jakarta.apache.org>
>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" <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: 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