Erik,
The simplest workaround is to pass any state info back and forth between the
client and the server:
But this of course requires either cookies or URL variables or form
submission on each hit on the server with the state info.
There is elegance in returning to the statelessness method - because most
pages don't really need state.
But for those that do like search results, and then getting the next set
etc. there is a elegant solution:
Creating "mini sessions" within sessions:
In the session scope create a SearchInfo Structure, then
Each time a user performs a search store the information in a structure and
insert it into the SearchInfo structure using a GUID as the key.
Pass this GUID on the URL of the next and previous buttons for scanning
search results.
Spawning a new window will get the same GUID on the URL but if then a new
search is performed you assign the new criteria to a new GUID therefore not
overwriting the first set, and thus both instances can work side by side and
not step on each others data.
The only cost, other than a bit of extra code, is extra memory usage as you
keep on adding mini sessions until this session times out and it's all
freed.
HTH,
Noam
P.S. you don't have to use GUID's any unique key will work.
----------
From: Erik Voldengen [SMTP:[EMAIL PROTECTED]]
Sent: Thursday, 01 March 2001 17:43
To: Fusebox
Subject: RE: Session VS. Client Vars
I doubt there is any elegant way around the problem that
Alan described. The only way I can think of is to not set
cookies to maintain state, pass CFID/CFTOKEN in the URL, and
require the user to start a new session. Maybe by giving
them a pretty little icon that said "click here to open a
new instance or it won't work right," worded with a little
more charm. At that point, getting the new CFID and CFTOKEN
is the sticky part.
The good thing about this problem is that it looks to be
consistent across all platforms, on all sites. If you could
start a new session with a browser spawn, that would be
cool, but I don't think the general public expects it
by any means.
-Erik
> -----Original Message-----
> From: McCollough, Alan [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, March 01, 2001 9:17 AM
> To: Fusebox
> Subject: RE: Session VS. Client Vars
>
>
> I think I know what Gary is runnin' into; its a problem I
> have and have yet
> to cure...
>
> With db-driven client vars, if a user pops open two browser
> instances, and
> proceedes to go in separate directions within the same app, things
get
> messed up, since the server has no way of identifying the two
browser
> instances as being independent.
>
> The problem is, both session and client vars will have the
> same problem,
> from what I can tell. If you set a session cookie, that cookie
isn't
> specific to a browser instance; its' specific to the user
> logged on the
> client box. So, that cookie is gonna work for all browser
instances.
>
> I mean, figure it like this. Somebody logs into my app. After
> logging in,
> they spawn another browser instance. Prior to ever hitting
> the server, how
> does the browser make itself look different when it passes
> that initial call
> to the server for the first time? It's basically a clone of
> the initial
> browser instance; and will inherit all the cookies and tokens
> assigned to
> the original.
>
> Really, from what I can tell, it would have to be a function of
the
> -browser- to somehow identify itself as being distinct from
> the original.
> Perhaps in the way it handles the acceptance/use of cookies?
> A specific UUID
> appended to all URLs? I think it has to be the browser that does
this,
> though; not the server.
>
> Alan McCollough
> Web Programmer
> Allaire Certified ColdFusion Developer
> Alaska Native Medical Center
>
> > -----Original Message-----
> > From: Douglas Smith [SMTP:[EMAIL PROTECTED]]
> > Sent: Wednesday, February 28, 2001 5:24 PM
> > To: Fusebox
> > Subject: Session VS. Client Vars
> >
> >
> > At 06:37 PM 2/28/01, Gary Morin wrote:
> > >Thanks, I was referring to having the browser running twice.
> > >
> > >My original thoughts were if the user starts up IE browser
> twice, to run
> > the
> > >same application twice, that one browser client variables
> would overwrite
> > >the other.
> >
> > {redacted}
>
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Structure your ColdFusion code with Fusebox. Get the official book at
http://www.fusionauthority.com/bkinfo.cfm
Archives: http://www.mail-archive.com/[email protected]/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
