Looks like the temporary storage used in the getTemp() method of TurbineUser is actually stored within a HashTable inside the instance of the TurbineUser, not directly in the container's Session so that's why you can't find anything directly associated with the Session.
If the information is User specific, I would just stick it in the User's temporary storage. This also saves the headache of possiblity (however slim) of name collisons within the Session itself. Scott -----Original Message----- From: Pugh, Eric [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 29, 2001 2:51 PM To: 'Turbine Users List' Subject: RE: Page Session Question 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]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
