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:47:10 GMT


Geoff Longman wrote:

>Ahh, but we're trying to reduce our dependency on the Visit. We have many
>groups of pages, and each group needs to store a distinct set of data. Our
>visit class was becoming a mess.
>  
>
So are you saying you need a separate class for each group of data? If 
so I am not sure how a SessionLocalService would help. And if not the 
SessionLocalService is going to become the same mess as the Visit. What 
you can probably do is write custom services and custom data objects and 
manage them from within the filter. So you could have a 
NewCustomerWizardService and NewCustomerWizardData and the data can be 
stored in the ThreadLocal from the filter like I said before. And the 
services would be singletons. We could wrap the HttpSession in a 
SessionLocalStorage service (like the ThreadLocalStorage) but you would 
still need the custom services.

>Plus, a session local service could also be useful outside of Tapestry where
>there is no Visit! No reason why a JSP couldn't use a session local service.
>
>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 10:14 PM
>Subject: Re: [Hivemind] Tapestry/HttpSession service
>
>
>  
>
>>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
>>
>>    
>>
>
>
>---------------------------------------------------------------------
>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