Hi Chris,
This is a question about which I am also wondering, given that
I have just implemented a "solution" to it. :)
It seems that there are several timescales over which shared
objects persist:
-Application (reference data, config.)
-Application per invocation (global state)
-User
-Session
-Request
Most of what I've worried about has to do with Sessions and
Requests. The Turbine framework seems to answer most of the
other questions well (with resources, the singleton-based
service framework, and the methods on User).
It sounds like your problem has to do with sharing/
cacheing objects at the Request level (I think of a Request as
a one-way thread of processing that comes into being and goes
away with each HTTP request to the server. Hopefully this is
close enough to the technical meaning of a thread, which I
understand corresponds closely to the RunData object.)
In any case, I didn't find a handy place to cache data in
RunData that wasn't session-scoped. The example you give
utilizes the Servlet session cache:
data.getSession().setAttribute( )
What I have done, since I am subclassing WebMacroSiteScreen
(soon to be VelocityScreen ;)), is to place request-scoped
objects into the WebContext (soon to be Context). If you
are subclassing a higher-level Screen directly then this isn't
an option, of course (no WebContext).
This feels a bit asymmetric to me, but seems to have the right
lifecycle (comes into being before most code that handles requests,
goes away after the response is generated). It was also the most
obvious place (to me) to pass things between an Action and
Screen that did not involve an underlying persistence layer
(although, sometimes it might be be appropriate to alter
the "model" portion of the application to reflect the
processing).
The screen subclass works to load this data transparently
(reflecting the effects of prior Actions); I'm still looking
for a way to create a corresponding base from WebMacroSiteAction.
For now, I just explicitly include code to place data
into the context:
context.put("requestDataPackage", requestDataPackage);
// where requestDataPackage contains info on
// current patient, task, form, etc.
I am also looking for an appropriate way to automatically
shoehorn processing before and after the appropriate do
methods in the Action, but that's another story.
Of course, we could always put request-scoped data into a
longer-live cache and then just clear it out or add code to
make sure it's always well-initialized.
Sorry for the ramble but you've tapped into an ongoing
question for me. Hope this helps,
Dave
P.S. Thanks for all your earlier replies to my colleague
Chris Crossen about O-R mapping. Your and Jon's feedback
has been helpful.
-----Original Message-----
From: Chris Kimpton [mailto:[EMAIL PROTECTED]]
Sent: Thursday, November 02, 2000 2:54 AM
To: turbine
Subject: How to send temporary stuff between actions and forms?
Hi,
I seem to remember responding to just such a question a few months back -
and now I don't remember what my answer - or if was correct!
What I am currently doing to pass information between actions and screens is
to put objects/strings into the session (ie
data.getSession().setAttribute...) Now this doesn't sound too good - as the
session stuff lives beyond an individual request - and the things I am
passing should not - it is things like what label to have on a button and
optional bits of text on a form.
So - anyone know what I should be doing? I'd have thought get/setTemp()
methods on the rundata object itself would be the way to go - these would
populate a map that was started from scratch for each request that is
serviced.
Thanks,
Chris
---
"surely it is madness to accept life as it is and not as it could be"
______________________________________________
FREE Personalized Email at Mail.com
Sign up at http://www.mail.com/?sr=signup
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
