>
> you can still cache the query if you want to. I reach my limit on the
> fusebox technique when it will clearly slow things down and make
unnecessary
> server calls. His example of having an act_ and then a dsp_ is perfectly
> fine, IMHO.
the point isn't a disagreement whether act_'s must follow or precede dsp_'s
.. No one argues that point. The point (supposedly) was to show that there
was some functionality that warranted a de rigeur cfinclude of queries in
the fusebox rather than the fuse. I submit the point has not been made,
although a good potential example for discussion has been proffered.
I think the example is a poor one because it uses the assumption of a
(potential) exception to dis-prove the rule. Only in the case Patrick cites
wherein you do some act_ (remember these are supposed to be changes to the
DB) and then want to show the old data using some dsp_ (lest some
intermediate act cause a db change or a refresh) does the example hold.
Which do you use regularly, exceptions or rules? Should all conditional
logic necessarily then be put into the fusebox because we might need an
exception (the "big-ass cfswitch" argument)? Or do we leave the exceptions
for the exceptions, and instead base rules on a general best-practices
techniques (which is what we're trying to figure out in this discussion
thread)?
Also, it begs the point of exactly what cache-ing safe issue is meant? It
seems to me that you get absolutely Zero certitude about the query being
not-cached between the two includes versus the double-fuseaction, except
potential execution time, any moreso than FB versus any other CF programming
methodology. There may even be a way to simulate what Patrick suggests using
XFA's which Hal might be able to suggest (I make an attempt below). But back
to the actual example, let me ask a really obvious question since
superficially this is why the example is offered up anyway: Our fuseaction,
in English, is "I'm gonna hit the DB to update some data, and then I'm gonna
display some *old* data to the user." Uh, why don't I just show the old data
to the user before I make the changes --that way I'm sure it's old data (in
fact at that moment, it is not "old" it is "current") and then hit the DB
with the new data ? Aren't I just doing two different, albeit related,
things?
Finally, the example also inherently assumes that the only method for
cfinclude-ing is from within the fusebox. Instead the Fusedoc spec actually
allows for files-that-are-required (the "+++" notation), which are typically
qry files but can also be custom tags, etc. which leads to:
<cfcase value="convinceNonXFBpeople">
<cfinclude template="showmeolddata-eventhoughnewdataexists.cfm">
</cfcase>
where "showmeolddata-eventhoughnewdataexists.cfm" consists of
<!---
|| BEGIN FUSEDOCS ||
|| Attributes ||
+++ qry_TheProblemQuery
+++ act_someotheraction
|| END FUSEDOCS ||
--->
<cfinclude template="querys/qry_TheProblemQuery.cfm">
<cfinclude template="act_someotheraction.cfm">
<!--- or possibly even <cf_act_someotheraction> if warranted --->
The real point is to ask what is the fuse actually doing? Is it displaying
information? Or is it changing data in the DB (or some other non-display
function)? Or both? If both, why is it only one fuseaction and not broken
into two pieces? Or as in the example, left as one fuseaction with any
required files Fusedoced and Included in the same template.
Ok, wow, I sure like to type. :)
Here is one more point. If you do it the XFB way, the entire thing is
documented within the Fusedoc of the same file from which the action occurs:
here, the file included at the fusebox level. Everything about the fuse,
including whether other files are included or called are all within the same
single file, the fuse file, and it acts like its own blackbox. You really
can get the 30,000 ft overview from a fusebox switch statement this way, and
then you drill down into the individual fuses to get the details--the only
thing missing from the fusebox that is potentially useful is the
"responsibilities" section of each fuse's fusedoc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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
