> Hm. I wonder (I know the answer but don't like it) if you can turn the
scope
> declaration into a variable! Imagine in your app_globals, <CFSET
> my_scope="session">, and then you'd say my_scope.username, my_scope.id,
> etcetera. Hoo that would be nice... Then you could flip it this way or
that.
Evaluating the variable :)
<cfscript>
my_scope="session";
Evaluate("#my_scope#.login = TRUE");
</cfscript>
----- Original Message -----
From: "McCollough, Alan" <[EMAIL PROTECTED]>
To: "Fusebox" <[EMAIL PROTECTED]>
Sent: Tuesday, April 03, 2001 6:21 PM
Subject: RE: Speed for Persistant Variables
> I'll toss in a caveat that I have yet to lick...
>
> With the client variable/WDDX scheme, although it works gangbusters, you
> will run into big problems if and when a user spawns a new browser
instance.
> The server has no way of knowing this new spawn is to be given a separate
> client store. When the user goes in two different directions with the two
> instances (and who amongst us hasn't done that?), you end up with a mess
on
> the server side. Is Joe Shmoe adding an item to the cart or is he removing
> one? Did he log out?
>
> The only solution I know works in a controlled intranet environment. Tell
> the users not to spawn multiple instances. That, however, is hardly a
> solution.
>
> Session scoping is a major hassle, what with the locking and all...
>
> There is a workaround you could build into your app.
>
> Basically, you can get away with doing a global find-n-replace with
> "session."/"client.". Of course, save your work first!
>
> Imagine, you could build in the WDDX serialize/deserialize component, and
> use it even if you were doing session vars. A bit more overhead, but you
at
> least would be able to try both ways out.
>
> Hm. I wonder (I know the answer but don't like it) if you can turn the
scope
> declaration into a variable! Imagine in your app_globals, <CFSET
> my_scope="session">, and then you'd say my_scope.username, my_scope.id,
> etcetera. Hoo that would be nice... Then you could flip it this way or
that.
>
>
> > -----Original Message-----
> > From: Ryan Wood [SMTP:[EMAIL PROTECTED]]
> > Sent: Tuesday, April 03, 2001 4:34 AM
> > To: Fusebox
> > Subject: Speed for Persistant Variables
> >
> > I am developing a fusebox app that will need a large user structure on
> > each
> > page. That nested structure could be fairly large housing security,
> > preferences, user data, etc. What is a best (most efficient) way of
> > persisting that variable. I currently have a couple of options.
> >
> > 1. Use the session scope [downside = locking; upside = persisent in
> > memory]
> >
> > 2. convert structure to WDDX packet and store as a client variable
(using
> > a
> > database). Then in myGlobals (XFB) de-serialize the packet into a
request
> > scoped structure. [downside = need to de-serialize and set the request
> > scope
> > variable at the top of each page. upside = no locking]
> >
> > which option would provide the best speed, scalability, and use of
memory?
> > Is there another option that I am not seeing?
> >
> > Thanks.
> >
> > __
> > Ryan Wood
> > [EMAIL PROTECTED]
> > SourceScape | www.sourcescape.com
> > 864.346.3342
> >
> >
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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
