(oops forgot to attach file. resending. sorry 'bout that)
A few days ago I posted a recommended new version of FormUrl2Attributes that
didn't throw exceptions like the current official one, ala
http://www.fusebox.org?index.cfm?eek
My attachment's MIME-Encoding got kind of messed up, so I'm reposting it as a
zip file attachment this time instead of cfm. Also, I fixed a small
inconsistency in the way my original post dealt with the Request.Attributes
list. It is now totally compliant with the original FormUrl2Attributes (i.e.
no empty values).
Below is a copy of the original email I sent to the list, just in case you
missed it.
Peace
--Brendan Avery / [EMAIL PROTECTED]
====================================================
Greetings fellow Fuseboxers. I think I was on this list a year or so ago but
somehow I lost track of it. Anyways, my name is Brendan Avery and I've been
using the Fusebox techniques for a year now -- kudos to Steve Nelson et al for
a very smart and efficient workaround to what would otherwise be major
shortcomings of the CF platform. Anyways, on to the reason for this email:
FORMURL2ATTRIBUTES will throw an exception when you have incomplete value-pair
in the query-string (when using the standard ? prefix.) For example, click
the following:
http://fusebox.org/index.cfm?oops
See what I'm saying? Kind of tacky. Of course, you could always code in an
exception handler via cf_try/cf_catch to redirect to the index.cfm within your
index.cfm, but that might not be the desired result for some circuit
applications (though it would probably be the most common, apart from a custom
error page.)
However, I suggest that an alternative to coding exception handlers in the
index.cfm would be a slight modification to the FormUrl2Attributes.cfm script.
See my modified version (attached); note I added very obvious comments which
could of course be truncated if this ever goes official.
ONE OTHER NICE ADVANTAGE of this modified version of FormURL2Attributes is
that it accepts any parameter declarations without an = sign and accompanying
value as a "TRUE" value, directly mimicing the behavior of a custom tag with
an unspecified attribute value. For Example, in the custom tag call:
<CF_MYTAG THISWILLBETRUE>
Within the MyTag.cfm, if you reference "attributes.thiswillbetrue" you will
get a TRUE value. This is the way cold fusion defines the default of an
unvalued parameter.
So, consider the following...
http://whatever/index.cfm?fuseaction=report&textonly&maxrows=15
With my modified formurl2attributes.cfm, you'll get the following attributes:
attributes.fuseaction = report
attributes.textonly = TRUE
attributes.maxrows = 15
value of attributes.textonly will be returned as TRUE just like it would be if
you made the following cfmodule call to the index page like so:
<cfmodule template="index.cfm" fuseaction="report" textonly maxrows=15>
(Most importantly, however, it won't throw an exception if the index is called
by HTTP.)
I had originally sent two emails to Steve Nelson regarding this suggestion,
but I he's too busy to answer, so I'm posting it here on the list to see
if anyone thinks this is a worthy addition to the official Fusebox release.
Thanks for your attention.
--Brendan Avery / [EMAIL PROTECTED]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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
