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
