Hi Hal,
I usually just put the conditional logic directly in the fusebox, following
the usual rules of optimum complexity. In other words, if the conditional
logic gets too involved, I'll have to shunt it out into a fuse somehow, but
that would not be my preferred option.
Basically, I want to be able to read the fusebox, and get a pretty good
understanding from that about the possible execution paths. I really don't
want to have fuses calling each other, except in very simple ways (as in
your old fusefunction examples).
My basic rules are probably the basic rules of FuseBox (haven't really seen
them written down anywhere though):
- Only the fusebox can call fuses (ie, a fuse may not call another fuse);
- A fuse may only have exit points leading to the fusebox.
A corollary of these rules is that some logic greater than the simple
CFSWITCH will inevitably end up in the fusebox's code.
(I think your fusefunctions are the only useful exception to the above
rules. To re-cap, these are called as CustomTags (or MODULES), and always
return a value, so that CF_XXX returns a value (or structure) called XXX. A
fuse may call a fusefunction, but the fusefunction must return execution to
the calling fuse, so that the potential increase in complexity is minor.)
Anyway, if your research turns up a better way to handle this kind of
situation, I'm all ears.
Lee.
>From: "Hal Helms" <[EMAIL PROTECTED]>
....
>Question on how you handle queries...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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
