Is the storage space the same when you do
data.getSession.getAttribute("myattribute")
and when you do
data.getUser().getTemp("myAttribute")?
I tried it, and they seem to not be the same... However, it seems that the
Pull service, if you create a pull tool with session scope, you get the
data.getUser() space to store data, not the data.getSession() space to store
data.
What are the benefits of one versus the other?
Eric
-----Original Message-----
From: Weaver, Scott [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, November 28, 2001 4:13 PM
To: 'Turbine Users List'
Subject: RE: Page Session Question
IMOHO, I would use the PersistantContext object and access it within your
templates via pull tool that acts as a facade. This makes PersistantContext
more readily available to actions and screens (and other servlets if
necessary) than if it where just in a pull tool. I always try to look for
the most flexible way to implement these types of things. 9 times out of 10
my pull tools are basically facades for services I have already written in
Turbine (Fulcrum?) anyway. Hey! There ya' go why not write a
PersistantContextService and access it with a PersistantContextTool ;)
Scott
-----Original Message-----
From: Pugh, Eric [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, November 28, 2001 3:56 PM
To: 'Turbine Users List'
Subject: RE: Page Session Question
Yes, you are right.. I guess I am not sure which way is better.. Use a
subclassed pull tool that has session scope. Or create a PersitentContext
and put it in the http session directly?
Although it is starting to sound like a subclassed pull tool would be
better..?
Eric
-----Original Message-----
From: Nathan Bubna [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, November 28, 2001 2:57 PM
To: Turbine Users List
Subject: Re: Page Session Question
why do you need both a PersistentContext and a separate pull tool? sounds
to me like they should be one and the same. what you want can most
certainly be done with a pull tool.
Nathan
----- Original Message -----
From: "Pugh, Eric" <[EMAIL PROTECTED]>
To: "'Turbine Users List'" <[EMAIL PROTECTED]>
Sent: Wednesday, November 28, 2001 11:42 AM
Subject: RE: Page Session Question
> It seems like there are a lot of ways of storing data, but none of them
seem
> to really be screen/action/.vm/user specific. What I really wish is that
if
> I had a private varialbe on my myScreen.java class, it would be there when
I
> next return.. And when someone else loads myScreen.java class, they would
> have their own instance of that variable.
>
> My problem with pullTools that are user/session scoped is that if my value
> name is "page_name", and I load it into the context on page A with the
value
> page A, I want that to be distinct form the value named "page_name" on
page
> b. With the pull tools, that is not possible.... Which means that I need
> to make sure that any value name that is specific to a page doesn't get
> reused elsewhere, causing random results.
>
> I am thinking that maybe my solution is something like this:
>
> A pullTool that is either user or session scoped. Probably session
scoped.
> Then any value put into something like the PersistentContext suggested
> earlier would have an additional key, the screen name. That way I could
> store something like this:
> Name Page Value
> page_name pageA "page A"
> page_name pageB "page B"
>
> But the API would look something like this:
>
> String pageName = persistentContext.get("page_name")
>
> And since the persistentContext would load the runData object, it would
know
> what page we are on, and return the correct value... It might also be
cool
> that an action with the same name as a screen would both have access to
the
> same set of data!
>
> And the persistentContext object would be stored either in the pullTool
> user/session scope or the store it in the http session directly.
>
>
> This obviously will take some serious thinking about, but seems like
> something that would make persistence between requests easier.
>
> I would welcome any comments, especially since I don't want to reinvent
the
> wheel, or end up doing something that is going to hurt the performance of
my
> turbine applications....
>
> If I feel that what I create is worth anything I will post back to the
list
> the source code.
>
> Eric
>
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, November 28, 2001 12:29 PM
> To: Turbine Users List
> Subject: RE: Page Session Question
>
>
> And lets not forget about (User/Session scope) PullTools! The PullService
> was made for this sort of thing.
>
> -B
>
> On Wed, 28 Nov 2001, Weaver, Scott wrote:
>
> > Eric,
> >
> > I am almost positive that context is request-based, so it's kind of a
one
> > way deal. After the request has been serviced that information is gone.
> >
> > You could write a PersistentContext class that is stored within the
> session
> > instead of the request and use a pull tool to retreive it within your
> > template. Heck, you could even take your context object and store it in
> the
> > session directly (I'm not sure if that's a good idea or not, though).
> >
> > doBuildTemplate(RunData data, Context context)
> > {
> > ....
> > //store your context into the container's session for this user
> >
> >
data.getRequest().getSession().setAttribute("persistant.context",context);
> > ...
> > }
> >
> > Scott
> >
> >
> >
> > -----Original Message-----
> > From: Pugh, Eric [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, November 28, 2001 10:49 AM
> > To: 'Turbine Users List'
> > Subject: RE: Page Session Question
> >
> >
> > Scott,
> >
> > That is definitly some great suggestions.. For a pageCounter, both
> > suggestions would be great... I looked at an earlier post I made, and
the
> > response:
> >
http://www.mail-archive.com/[email protected]/msg04250.html
> >
> > and realized that I have been trying to figure out this question a
couple
> > times.
> >
> > I am looking for a more generic approach for any data. I don't think I
> can
> > use static, because I want each user to have their own data. So if I
> store
> > something that is specific to a screen and a user, I don't want to put
the
> > data into the userobject, and can't make it static.
> >
> > The post I reference mentioned putting the data into the context. While
> > that seems a little weird to be putting data into the context, and then
> > copying it out when I am reloading my screen, it would work. However, I
> > can't seem to get it to work. If I put something into the context,
should
> > it be there when I reload the screen? Or do I have to do something
weird
> > like put the data in hidden fields on a form or something?
> >
> > I check the context with containsKey("pageCounter"), but always get
false
> > back when I reload the page.
> >
> > Eric
> >
> >
> > -----Original Message-----
> > From: Weaver, Scott [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, November 28, 2001 10:09 AM
> > To: 'Turbine Users List'
> > Subject: RE: Page Session Question
> >
> >
> > You might want to define the pageCounter as static within your screen
> class.
> > As long as everything is running in the same JVM, any changes made to
the
> > static member variable will be perserved until the container is shut
down.
> > You will probably want to write the pageCounter out to permanent storage
> > every so often as means to perserve it if the container is shut down.
> >
> > Another, more OO way would be to create a PageHit class that records
hits
> to
> > a HashTable using the Screen name as a key. Make it a singleton class
> with
> > protected constructors and static member variable that holds a reference
> to
> > itself. Also, implement serializable, so you could write the object to
> disk
> > to preserve it's state. Configure the class to write itself to disk
after
> x
> > number of updates if the container goes down suddenly.
> >
> > Just some suggestions,
> > Scott
> >
> > -----Original Message-----
> > From: Pugh, Eric [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, November 28, 2001 9:42 AM
> > To: 'Turbine Users List'
> > Subject: Page Session Question
> >
> >
> > Hi all,
> >
> > I seem to remember that with servlets, if I declare a private variable,
> and
> > then reload the servlet, the servlet remembers the variable. In
> otherwords,
> > a servlet can be made stateful...
> >
> > Does a similar thing exist with screens? To preserve data across
screens
> I
> > have put data in the user object. What about on a single screen?
> >
> > I added a private int pageCounter = 0 to my screen. Then in the
> > doBuildTemplate method I increment the pageCounter, and put it in the
> > pageContext. However, when I reload the page, the pageCounter is always
> 1,
> > it never seems to increment.
> >
> > How can I store data from one load of a screen to another? Putting
stuff
> in
> > the userObject sometimes seems kinda clumsy.
> >
> > Eric
> >
> > --
> > To unsubscribe, e-mail:
> > <mailto:[EMAIL PROTECTED]>
> > For additional commands, e-mail:
> > <mailto:[EMAIL PROTECTED]>
> >
> > --
> > To unsubscribe, e-mail:
> > <mailto:[EMAIL PROTECTED]>
> > For additional commands, e-mail:
> > <mailto:[EMAIL PROTECTED]>
> >
> > --
> > To unsubscribe, e-mail:
> > <mailto:[EMAIL PROTECTED]>
> > For additional commands, e-mail:
> > <mailto:[EMAIL PROTECTED]>
> >
> > --
> > To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> > For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
> >
>
> --
> brian lawler
> branuity
> 617 front | v: 415.217.5052
> san francisco 94111 | m: 415.307.5277
> [EMAIL PROTECTED] | f: 415.217.5060
>
>
> --
> To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
>
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
>
>
--
To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
