> - Both foo and foo2 are URL/form/custom tag variables that are always
> treated as constants by the fuses. The Attributes scope is effectively
> "frozen" at the fuseaction level... individual fuses never make changes or
> additions.
>
> - Parameters created by fuses for use within a single fuseaction are
> assigned to the default Variables scope. So qry_findthis.cfm might pass
> variables.qryFindThis to dsp_generatethis.cfm.
I'm afraid you're missing some of the best parts of Fusebox. In my apps,
most parameters could be either created/set in on of the fuses or passed
into the circuit.
> - Parameters that are part of a global collection are added to the Request
> scope. So in this case, dsp_generatethis.cfm creates a series of
> request.bodycontent.whatever variables, many of which will be used in
> tmp_showthis.cfm, and some of which will be used later in app_layout.cfm.
The request scope shared by all circuits, even those nested in custom tags.
If that's what I want, I use the request scope.
> All this has me reconsidering something, though. I'm wondering if I should
> start putting intra-fuseaction, inter-fuse variables into a variables.fuse
> structure, leaving the raw Variables scope for stuff that is
> purely local to
> a given fuse.
I'm thinking of doing exactly the opposite: Creating a structure that
would be used to store intra-fuse variables, in order to keep them from
conflicting with intra-circuit, inter-fuse variables. It would be nice if
CF had a template-specific scope.
However, I'm starting to consider the idea you suggest. (Actually, it's
sort-of been suggested by a bunch of people: Just replace "attributes"
with another name.) I'm thinking it may leave open possiblities for
changing the way we use fusebox (slightly) so that it solves problems
such as "the web is stateless" and "CF isn't OO."
> > Yes, I do that all the time.
>
> The idea literally never even occured to me. Perhaps because I
> still write a
> lot of custom tags, the Attributes scope has always had a very specific
> purpose in my mind.
I think it's a good idea, but because attributes has a specific purpose,
I don't think we should use attributes.
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
