Client variables all the way, because they are just so much easier than session vars. I've never noticed a performace problem, presumably because CF is smart enough to cache client variables and not go back to the DB every time it needs to read them. However, for really intensive use, I will copy them to the request scope at the start of the request, and then write them back to the repository at the end of the request.
I've found that I rarely want to store complex objects in client variables, so the lack of support is not really an issue. The couple times I've wanted to, WDDX is the perfect solution. As an aside for those sceptical of WDDX, it is INCREDIBLY fast, at least with small packets (say up to a query that's 20 fields by 75 records). my $0.02 barneyb -----Original Message----- From: Alan McCollough [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 04, 2002 9:13 AM To: '[EMAIL PROTECTED]' Subject: RE: forcing user to login Naw, if you are dealing with performance, all you gotta do is when you call a fuseaction (start through the big switch), get all the client vars up front and move 'em to a different scope like the request, attributes, or variables scope. When you are at the end of a fuseaction, and ready to do a CFLOCATE or something, write the variables back out to the client scope. If you've got arrays/structures, you'll need to WDDX 'em first, but that ain't a big hassle. --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.368 / Virus Database: 204 - Release Date: 5/29/2002 ==^================================================================ This email was sent to: [email protected] EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrFMa.bV0Kx9 Or send an email to: [EMAIL PROTECTED] T O P I C A -- Register now to manage your mail! http://www.topica.com/partner/tag02/register ==^================================================================
