commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "christian essl" <christiane...@yahoo.de>
Subject AW: Re: [Hivemind] Tapestry/HttpSession service
Date Sun, 07 Mar 2004 06:44:18 GMT
another try without a sessin-model actually quite simular to yours.

A ServiceFactory which is thread-local and delegates to another SerciceFact. the servicefact
checks if the implementation is already in the session if not creates it and returns. it also
keeps a list off all handed out implementations and right befor the request is over it stores
them back in the session - therefor it is thread-local or pooled. this factory is than used
from thread-local models. 

what do you think?

thanks,
chris
-----Original Message-----
From: "Geoff Longman" <glongman@intelligentworks.com>
Date: Sat, 6 Mar 2004 22:27:50 
To:"Tapestry development" <tapestry-dev@jakarta.apache.org>,       <commons-dev@jakarta.apache.org>
Subject: Re: [Hivemind] Tapestry/HttpSession service

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.

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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-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