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]>

Reply via email to