Re: [Hivemind] Tapestry/HttpSession service

Harish Krishnaswamy Sat, 06 Mar 2004 19:47:13 -0800

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" <[EMAIL PROTECTED]>
To: "Tapestry development" <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
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" <[EMAIL PROTECTED]>
To: "Tapestry development" <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
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" <[EMAIL PROTECTED]>
To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]>
Cc: "Tapestry development" <[EMAIL PROTECTED]>
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Hivemind] Tapestry/HttpSession service

Reply via email to