No NEED to cflock only read-onlys to application scope, but it's a darn good
idea. I'm sure that a heavily-hit site is capable of blowing up if you don't
do it, but more than likely you'll just get a slow site, as CF attempts to
do it's rudimentary locking on the application scope (which is an
undocumented, unconfirmed feature, but it sure seems like that's the case).
application.applicationname is a variable that is created in the application
scope once the cfapplication tag is executed, and its value is the name of
the application that you specified in the cfapplication tag. So yes, Hal
(and you) should lock the IsDefined("application.applicationName"). But then
again, after reading the previous paragraph, you might not care that much.
So about your last question in regards to cflocking all isDefined() calls,
it's a good idea. Allaire would say that the definitive answer is to cflock
them all.
NAT
> -----Original Message-----
> From: Bob Silverberg [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, March 28, 2001 3:28 PM
> To: Fusebox
> Subject: Checking for application.applicationname ( was RE: Nesting
> circuits: I just don't get it! :()
>
>
> Yeah, that's along the lines of what I was thinking. I have another
> question, which this made me think of.
>
> What's the deal with "application.applicationname"? Is it a variable
> sitting in the real application scope, or is it a structure in
> the variables
> scope that just happens to be called "application"? If the former,
> shouldn't we be CFLOCKing the IsDefined check, and if the latter,
> isn't that
> just really confusing? I wondered this when I read Hal's XFB 101 tutorial
> but forgot about it. I don't see how it can be a variable in the
> application scope, as it is being set everytime a page is processed by any
> user - and it doesn't even know which application it should
> belong to until
> after it has been processed. I guess maybe it's neither of the above -
> maybe it's just a magical "reserved word".
>
> While we're on the subject, I've never really been sure whether IsDefined
> calls to shared scopes need to be CFLOCKED. I always do it because a
> readonly lock doesn't really impede the application and I figure
> it's better
> safe than sorry. On the one hand, you can say that CF doesn't
> need to read
> the value, so the lock isn't needed. But on the other hand, it needs to
> interrogate the scope to determine if the variable exists, and if someone
> were trying to create that variable at the exact same time that
> might cause
> a problem.
>
> Anyone have a definitve answer on this?
>
> Bob
>
> -----Original Message-----
> From: Mike Craig [mailto:[EMAIL PROTECTED]]
> Sent: March 28, 2001 5:58 PM
> To: Fusebox
> Subject: RE: Nesting circuits: I just don't get it! :(
>
>
> Hal9000...heh...that's cute...I'm surprised somebody hasn't said that yet.
> I think you are basically right...if you want to "url" directly
> to a circuit
> you can, so long as that circuit is designed to stand alone. In
> his nesting
> examples, he shows a simple piece of code:
>
> <cfinclude template="app_locals.cfm">
> <cfparam name="attributes.fuseaction" default="home.home">
>
> <cfif not IsDefined("application.applicationname")>
> <cfapplication name="fuseboxworld"
> applicationtimeout="#CreateTimeSpan(1,0,0,0)#"
> sessiontimeout="#CreateTimeSpan(0,1,30,0)#"
> sessionmanagement="Yes"
> setclientcookies="Yes"
> clientmanagement="Yes"
> clientstorage="#request.db.main#">
> </cfif>
>
> <cftry>
> <cfif Not IsDefined("request.circuits")>
> <cfinclude template="app_circuits.cfm">
> </cfif>
> <cfcatch type="MissingInclude">
> No Circuits have been defined
> <cfabort>
> </cfcatch>
> </cftry>
>
> <cfmodule template="#request.localtags#/Nesting.cfm">
>
> .....so that the assumption is that if you are coming into this circuit
> through another application "home", it will become the "home" at
> that point.
> The only thing I changed here is that in the <cfif> statement checking for
> application.applicationname being defined is that I call app_globals.cfm
> (which in turn calls other app_ files to set up the display
> environment, et.
> al.). This will not be called if an application already exists.
> Does that
> sound right to you?
>
> Mike Craig
>
> -----Original Message-----
> From: Bob Silverberg [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, March 28, 2001 5:16 PM
> To: Fusebox
> Subject: RE: Nesting circuits: I just don't get it! :(
>
>
> Now I'm confused. I think all Hal's saying is that you can "point your
> browser to" different urls as the starting point of your app.
> That way you
> can test an individual circuit or a complete app. This isn't to say that
> you code that directory structure into your fuseaction calls (e.g., form
> actions, links, cflocations). You still call everything from a single
> fusebox. As I'm typing this I think I'm figuring it out - as I don't use
> the official "Hal9000" method. I think the key is that you specify the
> location of this "master" index in your myGlobals file (e.g., <cfset
> request.CFROOT="/whatever/">). You then call the master index using this
> variable. If you use <cfparam> instead of <cfset> then you can
> set this in
> each myGlobals file, and whichever one is called first will take affect.
>
> So if you call the app from the real root, you'd end up pointing
> to the real
> root index.cfm, but if you call the app from a subdirectory (by pointing
> your browser there), in order to test a circuit app, then the
> "master" root
> index.cfm would actually be the one in the circuit app's directory. I
> believe that circuits.cfm would be the same in each directory. (I
> don't use
> circuits.cfm - but I'm beginning to like the idea).
>
> Is that right, or am I just more confused now?
>
>
> -----Original Message-----
> From: Patrick McElhaney [mailto:[EMAIL PROTECTED]]
> Sent: March 28, 2001 4:44 PM
> To: Fusebox
> Subject: RE: Nesting circuits: I just don't get it! :(
>
>
>
> This is what I'm really interested in (quoted from an earlier post by
> Hal Helms -
> http://www.mail-archive.com/[email protected]/msg08051.html):
>
> "One nice thing about this is that you can test each circuit by itself
> (since
> it can run unchanged as either stand-alone or nested). In test mode, you
> just point your browser to www.mydomain.com/mySite/users. When you want it
> as part of the bigger picture, you just point your browser to
> www.mydomain.com/mySite and users fuseactions will still work fine.
>
> The drag and drop would occur if I were to make mySite part of a bigger
> application, AllSites. Then I would just create another fusebox for
> AllSites, drag MySite into it, and register mySite in the
> Circuits.cfm file
> and everything else would work without being changed."
>
> You guys are telling me I can't do that. Is that right?
>
> Patrick
>
> > -----Original Message-----
> > From: Mike Craig [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, March 28, 2001 4:27 PM
> > To: Fusebox
> > Subject: RE: Nesting circuits: I just don't get it! :(
> >
> >
> > Never might be a strong word, but yes, that is true. This is why the
> > application root is the only "home" you have and your request.circuits
> > structure plus the fuseaction help navigate your tree.
> >
> > Mike Craig
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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
