Sean, the tutorials on arrays and structures don't have anything to do with
the Extended Fusebox techniques. I just did those to help people struggling
with mastery over those. There's a separate section called "Extended
Fusebox" that talks about nested fuseboxes and exception handling. I'll be
contributing more to this over time. In addition, I have tutorials at
www.halhelms.com (free, even!) that may help.
Please understand that (a) Extended Fusebox is quite new and things are
still being worked out and (b) I'm trying to fit documentation in to a busy
schedule. I have to make money to keep the electricity on to let me write
the free docs! As for the site, you don't have to reverse engineer the
database. If you open up the qry files, you'll see calls to <cf_QuerySim>
commented out. If you make sure you have the QuerySim tag (available for
free on my site), you can just uncomment those query sims, comment out the
real db stuff and things will run fine.
You're absolutely right about the dot notation: an XFA like "home.main"
indicates that the directory is "home" and the fuseaction is "main". It is
the combination of those two that uniquely identifies a fuseaction. Extended
Fusebox allows circuits to be nested under circuits to be nested
under...well, you get the point. Because of the way this is done, you get
inheritance going "down" the tree and exceptions "bubble up" the tree,
allowing the developer to catch them at whatever point is appropriate.
The errorCode on the qry files was put there to allow query sims to work,
prior to having real queries. And yes, it could have been done in a global
include file. As for including qry files from the dsp files, this is a
stylistic thing and works just fine putting them in the index.cfm file
instead. In fact, Steve has recently convinced me that it makes more sense
to do as you suggest and just include them in the index.cfm file. I
initially didn't like the idea, as it meant that two files were linked
without making this dependency explicit. I've since seen that this can be
handled by an entry in the Fusedoc.
Let me reiterate a point I made earlier: this isn't Fusebox 3.0. There's
nothing wrong with Fusebox 2.0. Of course, there can be improvements, etc.,
but the thing I've created with wireframes, prototypes, devnotes, query
sims, nested fuseboxes, bubbling exceptions, assertions, XFAs, etc. is part
of an entire development methodology that I call "Extended Fusebox". It's
something I developed to deal with the problems of creating large-scale,
complex sites in a distributed development environment. Steve, Nat, and
others have been involved in it, but it's not meant to replace Fusebox.
You're not "missing the boat" if you never adopt it at all.
I know it's hard tackling something new, especially when the docs are
sketchy. I'm working to make the concepts clearer and I hope this helps just
a little bit.
Hal Helms
== See ColdFusionTraining.com for info on "Best Practices with ColdFusion &
Fusebox" training ==
-----Original Message-----
From: Sean Renet [mailto:[EMAIL PROTECTED]]
Sent: Thursday, February 08, 2001 7:34 AM
To: Fusebox
Subject: Re: FuseBox 3.0 dot notation concepts and frames.
You lost me Hal. What do 1d 2d arrays and structures have to do with the
dot notation format of extended fusebox? I was actually looking for more of
a white paper to see where this was headed. Does something like that exist?
It looks like a java directory structure. Is it? I haven't gone thru the
whole app I downloaded from your site (I think I am going to have to reverse
engineer the database to get thru the whole thing properly), but it appears
that you have an XFA that is something like home.main and home tells you
what directory the index.cfm is in and main would be that index's actual
fuseaction. Is that what yer doing? Is there some performance boost to
this instead of just pathing from the main index.cfm as usual?
Why are you paraming <cfparam name="errorCode" default="0"> on every qry_
page? Shouldn't this just go in app_locals or app_globals?
If this is really headed toward fuseactions by structures wouldn't it be
easier to build your href's and forms with a tag using cfassociate?
eg., <a
href="#self#?fuseaction=#attributes.XFA.addBookToCart#&itemNumber=#attribute
s.itemNumber#&#client.URLtoken#">Buy this book</a>
It seems to me if you are using the XFA's as some sort of java notation then
you could just send those query string parameters into a tag and let it do
the work instead of typing it over and over again
Are we really going to be doing query includes on the actual dsp_ pages
instead of the directory's index.cfm in the fuseaction case statements?
What is the point of that? Why not just have the query on the dsp_ page
then?. I think if you move this stuff to the dsp_ pages you lose the ease
of reading and head toward monolithic templates....
I know I have been buried, but did you guys change the whole structure while
I was MIA?
Please don't mistake my questions for criticism, I am just trying to figure
out where this is headed and what it is...
Nat, I looked thru fusebox.org and couldn't figure out which presentation
you were talking about.
I think I am signed up at SecretAgents, so I will go digging around the
tutorials there and see if anything there looks like this....
Sean Renet
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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
