I just used StructGet() instead of:
<cfif NOT IsDefined("session.shared.foo")>
<cfset session.shared.foo = StructNew()>
</cfif>
I forgot some init code:
<cflock scope="session" type="exclusive" timeout="10">
<cfif NOT IsDefined("session.shared.foo")>
<cfset session.shared.foo = StructNew()>
<cfset session.shared.foo.bar = "">
<cfset session.shared.foo.fighter = "">
</cfif>
</cflock>
<cflock scope="session" type="readonly" timeout="10">
<cfset variables.shared = session.shared.foo>
</cflock>
This should fix the exception that is thrown if the key "bar" does not
exist. Really, I am only using the session scope as an known location for a
shared scope. After the initialization is done, it could go away and any
components that had been created prior to its [session scope] destruction
would still all be linked to the same common structure. It just couldn't be
found in the session scope any more. This would be a problem if you created
more components later on that needed to be linked to the previously created
ones, but that is another issue that could be solved by storing it in the
application scope instead of the session scope.
Paul Kenney
[EMAIL PROTECTED]
916-212-4359
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Behalf Of Sean A Corfield
> Sent: Wednesday, April 21, 2004 2:52 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [CFCDev] Static variables
>
>
> On Apr 21, 2004, at 12:53 PM, Paul Kenney wrote:
> > <cfcomponent name="foo">
> > <cfset variables.shared = StructGet("session.shared.foo")>
> >
> > <cffunction name="getBar" returntype="string" access="public">
> > <cfreturn shared.bar/>
> > </cffunction>
> > </cfcomponent>
>
> I'm a little confused by this example...
>
> I'm not sure why you use StructGet("session.shared.foo") - don't you
> mean just session.shared (i.e., bind variables.shared to
> session.shared
> - which should already exist as a struct).
>
> Otherwise your getBar() method will return
> session.shared.foo.bar (or,
> more likely, an error)?!?
>
> BTW, I would be consistent with the scope prefix:
>
> <cfreturn variables.shared.bar />
>
> Personally, I think this sort of aliasing is a Bad Thing(tm) for
> several reasons: 1) CFCs shouldn't depend on shared scopes
> (i.e., their
> environment) unless they are specifically acting as a fa�ade for data
> in the shared scope; 2) aliasing a stateful CFC onto a session scope
> variable creates two names for the same thing which could cause
> maintenance problems; 3) your stateful CFC cannot be stored in
> application or server scope (a Session Fa�ade should be a
> stateless CFC
> that accesses session scope on-demand and therefore it can be
> stored in
> application scope since it is a service CFC).
>
> Sean A Corfield -- http://www.corfield.org/blog/
>
> "There are no solutions, only trade-offs."
> -- Thomas Sowell
>
> ----------------------------------------------------------
> You are subscribed to cfcdev. To unsubscribe, send an email
> to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev'
> in the message of the email.
>
> CFCDev is run by CFCZone (www.cfczone.org) and supported
> by Mindtool, Corporation (www.mindtool.com).
>
> An archive of the CFCDev list is available at
www.mail-archive.com/[EMAIL PROTECTED]
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email
to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev'
in the message of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported
by Mindtool, Corporation (www.mindtool.com).
An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]
