Sandra,
In which cases would you not take a structure, array or record set and
convert it to a client variable the wddx route? If you are doing any sort
of dynamic data collecting and retrieving it is simply easier to code using
wddx anyway. To scare someone away from client variables because in and of
themselves they cannot be structures isn't good advice. Hmmm lets see to I
hand my state management over to the powers that be or do I write on extra
line of code to store a structure as a client variable? I think I will
chose the latter. I cannot think of one good reason to use session
variables in a production enviroment. They are simply not safe. The fall
under the "well you can use them, but they are not a good idea" category of
programming.
I was not suggesting he do a wholesale search and replace, I was showing
him that it is not hard to use them. (eg., "Now everywhere you would
normally put session.myvar, just use client.myvar")
----- Original Message -----
From: "Sandra Clark" <[EMAIL PROTECTED]>
To: "Fusebox" <[EMAIL PROTECTED]>
Sent: Friday, February 23, 2001 4:00 PM
Subject: RE: cflocation, addtoken = yes||no
> Actually that is not quite true.
>
> Client Variables can only store simple data types, ie strings and integers
> and the like. They cannot store structures, arrays, or recordsets,
Session
> variables can. You can convert those type of variables to a simple string
> via WDDX and reconvert back when you need to use them, but unless all the
> Session variables you work with are simple data types, doing a wholesale
> search/replace is going to cause a lot more trouble.
>
> Also be careful with storing the results of recordsets in Session
variables
> and trying to use Duplicate() to a Request scope.
> It caused my CF server 4.5.1 to bomb.
>
> -----Original Message-----
> From: Sean Renet [mailto:[EMAIL PROTECTED]]
> Sent: Friday, February 23, 2001 3:32 PM
> To: Fusebox
> Subject: Re: cflocation, addtoken = yes||no
>
>
> well the nice thing about client variables is that thier use is
transparent.
>
> All you have to do is enable client variable storage in your cf
> administrator..
> 1.Click VARIABLES
> 2.Choose your app's DATASOURCE
> 3.Click ADD
> 4. input the number of DAYS you want cf to keep the variables stored
> 5. make sure "CREATE CLIENT DATABASE TABLES" is checked
> 6.click CREATE
>
> Then in your application.cfm set the CLIENTMANAGEMENT attribute to yes,
and
> set CLIENTSTORAGE equal to your DATASOURCE from above.
>
> Now everywhere you would normally put session.myvar, just use client.myvar
>
> To delete client variables individually, use <CFSET temp =
> DeleteClientVariable("myvar")>
>
> To delete all client variables, do something like...
> <CFLOOP list="#getclientvariableslist()#" index="counter">
> <cfset DeleteClientVariable("#counter#")>
> </CFLOOP>
>
>
> ----- Original Message -----
> From: "Clint Tillerson" <[EMAIL PROTECTED]>
> To: "Fusebox" <[EMAIL PROTECTED]>
> Sent: Friday, February 23, 2001 2:12 PM
> Subject: Re: cflocation, addtoken = yes||no
>
>
> > Thank you Sean, I have seen the light, I think!!!
> >
> > I REALLY appreciate the time you took to explain all of that.
> > Sounds like I need to rethink how I manage state. Most of our
> > apps are password protected Intranet systems with a small number
> > of users. We maintain user info in a database and try to limit
> > session vars to a few user details grabbed when a user logs in.
> > However, most of our systems are data entry or filtering/reporting
> > systems and we have to track a lot of variables throughout a user's
> > session as the user sets data filters and jumps around the app.
> > Those variables are generally passed from page to page as form
> > variables or packed up for WDDX and put in a hidden form field.
> > This seems to work OK.
> >
> > I've never messed with the the database storage of client vars. I
> > guess its a bit of a fear of the unknown. But sounds like that is the
> > way it should be done.
> >
> > Thanks
> >
> > clint
> >
> >
> >
> >
> > On 23 Feb 2001, at 13:26, Sean Renet wrote:
> >
> > >
> > > Lemme splain.
> > >
> > > >From the docs...
> > > "Application and Session variables are in-memory variables, therefore,
> > > using them can increase the total amount of memory used by the server"
> > >
> > > When you use the setclientcookies param in cfapplication (I beleive
> > > the default is yes anyway) what this does is store the users cfid and
> > > cftoken in a cookie on thier machine. The actual session variables
> > > are in your servers memory and the cfid and cftoken are pointers to
> > > the space in your servers memory where these variables exist for this
> > > user. This of course is why you must lock your sesssion variables
> > > because there is a lot of grey matter floating around and you want to
> > > make sure you are using the right part. But I digress. The reason
> > > you must set cflocation's addtoken attribute to yes is that it passes
> > > cfid and cftoken (the pointers) with the request. Now someone might
> > > argue that that is not necessary because cfapplication is always
> > > looking for that cookie anyway. However, not passing this token can
> > > give you some funky ass results (as steve puts it).
> > >
> > > When I first started developing CF I was a session variable junky, but
> > > here are some reasons never to use them. First of all, they are
> > > stored in memory. This is bad. Your server's memory has enough to
> > > deal with without having to keep track of session variables. What if
> > > the server burps while you are in the middle of someone's session?
> > > That is, lets say some task whether server related or application
> > > related spikes the ram. Your session variables are wiped out and you
> > > go hungry a bow bow bow. Second, what do you do with paranoid web
> > > users that do not have cookies enabled? Or worse with a user that had
> > > thier paranoid friend set up thier browser? The latter has no idea
> > > how to enable thier cookies, the former thinks you can look through
> > > thier bedroom windows and is lost as a user. Now lets say you want to
> > > maintain state over several visits. Like someone comes to you website
> > > and you remember thier preferences. Now lets imagine this website is
> > > hosted on a shared server at some half-witted Hosting company.
> > > Something goes wrong on the server so thier solution is to reboot the
> > > machine. Guess what happens to your pointers and in memory variables?
> > > That's right, you go hungry. The problem with session variables is
> > > that you ultimately give up state management control.
> > >
> > > On the other hand, client variables can be stored both in the database
> > > and in the cookie. Now wherein if you do not store them in the
> > > database you still may have token problems if a server is rebooted.
> > > That is the cfid and cftoken for someone's browser may change.
> > > However, a ram spike is not going to kill your session. The safest
> > > way to maintain state is with client variables stored in the database.
> > > It makes handling stuff like wddx a breeze, you don't give up state
> > > management, and if next thing you know ole jed's a millionaire,
> > > clustering is transparent.
> > >
> > >
> > > Sean Renet
> > >
> > > ----- Original Message -----
> > > From: "Clint Tillerson" <[EMAIL PROTECTED]>
> > > To: "Fusebox" <[EMAIL PROTECTED]>
> > > Sent: Friday, February 23, 2001 6:29 AM
> > > Subject: Re: cflocation, addtoken = yes||no
> > >
> > >
> > > > I'm using session variables and NOT client variables. So, yes, I am
> > > > maintaining state with cookies. But how do these cookies interact
> > > > with cflocation. My understanding is cookies are not passed with a
> > > > cflocation, so how does cf know my cfid and cftoken immediately
> > > > following a cflocation if cookies are not passed and addtoken=No? Is
> > > > it simply because I am the only user at the time?
> > > >
> > > > (BTW, this is a corporate Intranet site with few users. I'm using CF
> > > > 4.01, hoping to go to 4.5 soon.)
> > > >
> > > > Actually, this raises another question. I understand for
> > > > clustering, you need to use client variables. But for a low profile
> > > > site such as this, I don't feel that will ever be a need. Is
> > > > clustering the ONLY reason there is a preference to client variables
> > > > over session variables. I always use session management and never
> > > > use client managment. I'm wondering if I need to re-think this.
> > > > What are the advantages/disadvantages?
> > > >
> > > > This concept has alluded me for some time.
> > > >
> > > > All of your comments are greatly appreciated. This listserv is a
> > > > great resource!!
> > > >
> > > > clint
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On 22 Feb 2001, at 18:06, Ken Beard wrote:
> > > >
> > > > > probably the reason you are still seeing everything work is that
> > > > > you are maintaining state with cookies.
> > > > >
> > > > > At 01:57 PM 2/22/01 -0500, you wrote:
> > > > > >Does the "addtoken" attributue of <cflocation> refer only to
> > > > > >their display in the URL? i.e., Will your site perform the same
> > > > > >regardless how you set this attribute? If you set addtoken = No,
> > > > > >are they still passed? In development, this seems to be true,
> > > > > >but I'm worried whether sessions will be lost or confused in
> > > > > >production with multiple users. If it doesn't matter whether you
> > > > > >set it Yes or No, why would anyone ever set addtoken = yes?
> > > >
> > > >
> > > >
> > >
> >
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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
