John Quarto-vonTivadar said:
> I think the example is a poor one because it uses the assumption of a
> (potential) exception to dis-prove the rule.
And earlier he said:
> > if someone could present a decent example of something that
> > can be done with a query included by a fusebox which also cannot
> > be done (ro at least done as easily) with a query included by the
> > fuse, I'd love to hear it--for me that's the ultimate test for
> > which stylism to choose.
But anyway, John, I think you're right. The example I gave is not
common, and doesn't sufficiently disprove the rule.
The reason I started moving the queries to the fusebox was to make
reusing forms easier. And I actually adopted another technique in
the process.
I want to reuse a dsp_ file that contains a form for adding new data,
modifying data that I just entered and was kicked back to me, and
modifying old data from a query. The common solution to this is
CF_ReuseForm, but I was never happy with that.
So I modified my qry_ file so that it doesn't return a query, but
actually sets the attributes variables for each field.
<!--- qry_product.cfm--->
<cfquery name="temp" ...>
SELECT * FROM products
WHERE productID = #attributes.productID#
</cfquery>
<cfset attributes.productName = temp.productName>
<cfset attributes.productDescription = temp.productDescription>
<cfset temp="">
Then on the dsp_form.cfm file, I use cfparams to set default values
for each field.
<!--- dsp_productForm.cfm --->
....
<input name="productName" value="#attributes.productDescription#" ...>
<textarea
name="productDescription">#attributes.productDescription#</attributes>
My fusebox looks like this:
<cfcase value="addProduct">
<cfset xfa.submitForm = "insertProduct">
<cfinclude template="dsp_productForm.cfm">
</cfcase>
<cfcase value="editProduct">
<cfinclude template="qry_product.cfm">
<cfset xfa.submitForm = "updateProduct">
<cfinclude template="dsp_productForm.cfm">
</cfcase>
Basically, what I've done is extended the idea of abstracting away
a paramter's point of origination. I've added queries to custom
tag attributes, url variables, and form fields. This allows me
to reuse queries A LOT more. For example, sometimes an act_ file
needs information that I may supply via a form/url in one
fuseaction and derive with a query (that I've already written)
in another fuseaction.
And there are other advantages. For example, I may be able to guess
the values for some form fields (such as the poster's name when
posting a message in a forums app). Pulling that information in is
simply a matter of dropping in a query that I've most likely
already written for another purpose.
So I do think there are some real advantages in not tying
qry_ files directly to act_ and dsp_ file, and instead putting
them in the fusebox, but a lot of that depends upon
maximizing the use of the attributes scope.
You made the point that you want the database as far away
from you as possible. I don't think burying queries so deep
the architect can't see them provides a solution, but abstracting
the queries away from the developer does.
Patrick
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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
