Here are some things to consider:
1) Fuses tend to be mostly bread and very little meat.
Except for act_ files, fusebox files have virtually
no business logic. (In fact, even act_ files usually
don't have much.) If you precisely define the
interface for a fuse, you've basically written
pseudocode for the whole fuse.
2) You have names and types. What about values?
I'm surprised no one has suggested a syntax to define
what the value of parameters might be. "How long can
the string be? Does a number have to be a positive
integer?" Has anyone considered rolling fusedocs,
Jeff's Harness, and Hal's Assertions into one
custom tag?
3) Fusedocs are the first prototype.
I've often rethought my designs because I couldn't
figure out easy ways to fusedoc them. This usually
results in breaking the fuse up into smaller, more
manageable pieces.
4) Maintenance.
I change my fusedocs often, both during initial
development (because I take an iterative approach
to design) and in changes to existing code. I don't
want to spend as much time updating my fusedocs as
I do the code.
5) Peons are smarter than servers.
Suppose I have a fusedoc called qry_getUser.cfm. It
has [userid] and [username] as incoming parameters.
I'm sure with that information alone, you can guess
what I mean. The information isn't sufficient for
Harness to understand, but Harness will never fully
"understand" how your application is supposed to
work anyway.
6) Rules are made to be broken.
I'd like to see a lightweight, nimble standard that
covers 90% of the situations I encounter flawlessly.
If I can communicate the other 10% more clearly with
slight deviations of that standard, I'd be willing to
do so.
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
