referring to something (a structure, component, etc.) in the session
scope that'd be returned by reference, and the members assigned inside
of Request.Session are being made to point to something residing in
session?
-joe
-----Original Message-----
From: [EMAIL PROTECTED] [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Monday, June 14, 2004 12:33 PM
To: CF-Talk
Subject: request scope combined with application???
Could someone tell me the benefits of having variables in a request
scope and in a structure loaded in the application page like below:
<cfset Request.App.dsn = "myDSN" />
<cfset Request.App.HTTP = "http://" />
<cfset Request.App.HTTPS = "https://" />
I'm suspicious these are persistent scopes loaded into request scope
since I also found this:
<cfset structLoginCheck = secLoginStatus() />
<cfset Request.Session.LoggedIn = structLoginCheck.Status />
<cfset Request.Session.UserName = structLoginCheck.UserName />
I understand using the request scope for dsns etc., but I don't
understand using the request scope with structures or as the notes say,
application scope (hope to find that soon!). It would seem to be
inefficient and defeat the purpose to load these values into both a
persistent scope and a non-persistent scope. If these really are just a
structure in the request scope, I still would think it's unnecessary
complexity if not inefficient. Could some one enlighten me on any
merits of doing it this way or confirm the inefficiencies? Is this
somehow a trick to eliminate the need to lock variables?
_____
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
