Luke,
you're almost there. I think actually you're thinking this way more complex
that it really is, but that is a problem in the heretofor explanations of
XFB, at least when those are done by email. In person, people seem to 'get
it' a lot quicker. Got to figure out why, since this seems like a sticking
point.
Anyway, the list you give below is accurate...except I'd like to make two
points
1) you don't need ALL of the below to do XFB. Since you've been talking
about nested circuits, you only really need the first 5 you list , plus
associated custom tags. In fact as you go further and further down your list
there are a lot of good things in there, and I hoep most of them get adopted
but really, after #5, you're moving fairly quickly towards "Personal
Practices"
2) more important, and so far after reviewing the thread I see that only Lee
has touched on this: if you are going to nest circuits and you don't
need/want/aniticpate those circuits to run on their own accord, then you do
NOT need app_globals.cfm, or circuits.cfm etc in the sub-circuits directory.
I tend to put them in, but with nothing in the files, just so that I have a
whole skeleton if I have to go back later.
I also like the idea that if I don't intend for the circuit to be called on
its own in an app, that it will at a minimum "break" for lack of appropriate
data in the app_globals.cfm if someone tries to call it directly.
Only the app_globals.cfm and Circuits.cfm etc of the ROOT will be called
which is how the sub-circuits "inherit"--if you review the code in
CF_Nesting and a typical XFB index.cfm you'll see that if you were walking
through it as a sub-circuit then virtually all of the references to
including other files are part of CFIFs that are false --so they never
occur.
Personally the largest number of sub-circuits I've employed so far in one
app was 46, and that was when I was on a kick where all the CRUD's for
primary tables in the DB "had to" have their own circuit. All but 3 of the
46 were circuits that would never ever be called on their own. When we went
to version 2 of that same app I decided not to be nearly so anal, in the end
we had the home circuit, and 6 subcircuits. None of the many
sub-sub-circuits that were combined ever resulted in a new sub-circuit that
needed to run on its own. So I guess the lesson learned is that (a) ask
yourself if you really NEED that extra circuit ? and (b) mostly when the
circuit is going to be run on its own, you either implicitly know that from
the beginning, or its a whole new app and you're cannibalizing code from an
earlier app where the circuit didn't run on its own but now in the new app
it has to, and (c) consider using multiply-named circuits
As an aside I'd also mention that originally XFB used myGlobals.cfm in place
of app_globals.cfm because with XFB there is no need for app_locals.cfm (and
Hal disdains underscores). Early XFB also uses myServer.cfm which is
cfincluded from MyGlobals.cfm and serves as a place for setting of vars
pertinent to the physical server, rather than for the vars pertinent to the
application only. (nice, cuz then if you put the app on another machine you
only have to open up myServer.cfm. anyway it's not like that is a new idea!
:) )
One final note. This is something I don't think gets enough "press" (In
fact, when I mentioned this to Hal he seemed surprised like it was a new
idea to him). You can multiply-name the same circuit with different names.
For example, suppose I have a circuit just for Customers
(create/read/update/delete). yeah maybe I do some other stuff there but
let's keep it simple. I also have another circuit for Vendors, same kind of
stuff. Now as there is nothing wrong with having these in two sub-circuits,
you might have entries in your top-level Circuits.cfm that look like:
<cfset request.Circuits = StructNew()>
<cfset request.Circuits.home = "home">
<cfset request.Circuits.customers = "home.customers">
<cfset request.Circuits.vendors = "home.vendors">
ok no problem.
now, suppose someone decided they wanted to have both the code for Customers
and for Vendors in the same circuit, maybe called People. Now, the
Circuits.cfm might look like
<cfset request.Circuits = StructNew()>
<cfset request.Circuits.home = "home">
<cfset request.Circuits.people = "home.people">
[Note that the "dot" in the circuit value is a substitute for a slash and
refers to a directory on the physical drive; well you probably knew that
already.] Here's the rub: there is nothing in particular that requires that
the name of the circuit has to be the same as the name of the directory.
Most of the time of course you WANT these to be the same, but you can as
easily name them diffrently, as in
<cfset request.Circuits = StructNew()>
<cfset request.Circuits.home = "home">
<cfset request.Circuits.people = "home.importantpeople">
But you can also multi-value this circuit, like
<cfset request.Circuits = StructNew()>
<cfset request.Circuits.home = "home">
<cfset request.Circuits.vendor = "home.people">
<cfset request.Circuits.customer = "home.people">
this part is great because now if you switch code between having them in a
single sub-circuit versus individual circuits, you don't have to change any
references to it in the code---when I go to a XFA of "vendors.addVendor" it
will go to wherever I have pointed to in the Circuits.cfm, be that a circuit
with only Vendor code or the combined circuit with a whole mess of code in
it. And, if I do have a big-ass circuit with lots of fuses in it, I can use
the naming space to give more meaningful names to the "circuit.fuseaction"
combo. This is beneficial since the app is more portable when its naming
convention are not forced to be linked to some underlying directory
structure.
So if you do have all that those extra circuits and wish to bring things all
together then just pay attention to your Circuits.cfm and you can do it
quickly and easily. And if you anticipate potentially breaking certain
circuits up later on, then just multiply-name that circuit and the split
will be as simple as creating a new directory later on.
I hope that adds to what Lee already helped you with,
John
> Yeah - I'm beginning to see the logic there now, and it does seem to be
> almost too good to be true. Just to confirm - each circuit should have the
> following files:
>
> app_globals.cfm
> app_circuits.cfm
> app_layout.cfm (I am using the bodycontent.cfm custom tag - brilliant)
> Application.cfm (to prevent users from viewing files other than the
> index.cfm)
> Index.cfm
> scripts.js (local javascript functions)
> styles.css (local stylesheet)
> blocks/dsp_header.cfm
> blocks/dsp_footer.cfm
> Queries/qry_queryname.cfm (contains all query files)
> Actions/act_actionname.cfm (contains all action files)
> display/dsp_displayname.cfm (contains all display files)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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
