-----Original Message-----
From: Reuben King <[EMAIL PROTECTED]>
Newsgroups: cf-talk
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Wednesday, April 12, 2000 2:22 PM
Subject: Re: Session Variables and Multiple Browser Windows
>You must NEVER assume a stateful connection with HTTP!!!!!! Never,
>ever, ever! If you are performing a task that requires a stateful and
>sequential series of events, I might suggest looking at creating your
>own session variable management system.
I hear you, but I'm not sure that a roll-your-own session management
system could easily avoid these problems.
Hear's an example - mostly a navigational problem. You have a simple
drill-down application that goes SEARCH > LIST RESULTS > EDIT > SAVE. Now
say you want to return to the search results, or you may have several
additional layers through which you've "drilled" and at any one you'd like
a link to take the user back to the search results. Now, there are any
number of ways to "save" the query or it's results. You could keep a list
of record id's, or save the query parameters, or even save the query
itself in a variable. I've read numerous posts regarding storing queries
within session variables.
Now what happens when someone opens two windows, does different searches
within each and then drills down. Using CF session management, a "return
to search results" link will return the user to the results of only the
most recent query in any window that is open. Now, if you did your own
session management, I suppose you could make a decision to create a new
session with each query, then pass the session identifier along as a
hidden form field or URL parameter. But there can easily be other
"branching" points within the application and you'd somehow need to
instantiate a new sub-session or somesuch at each point. This sounds like
a nightmare.
It's sounding like avoiding any sort of session management altogether and
working within those limitations might be the safest bet.
>In the example of your current record ID, this is also something that I
>would keep persistent in the URL or as a hidden form field, not as a CF
>session variable.
This was just an example, but I think it illustrates what many beginning
CF programmers are trying to accomplish with session variables. I see a
bit of it in my office with new developers coding fairly complex
applications and I'm worried about the problems that could be caused by
multiple browser instances. We're moving numerous intranet applications
from Access based to browser based. I commonly see our users opening two
and three instances of those Access applications on their desktops and I'm
starting to worry about the implications of their doing the same with
browser based applications.
Jim
------------------------------------------------------------------------------
Archives: http://www.eGroups.com/list/cf-talk
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/cf_talk or send a
message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
