> What do you do when you need to create a parameter in one
> fuse and pass it to another?
Patrick,
It depends on the nature of the parameter. Let's take a pseudo-CASE:
<cfcase value="something">
<cfparam name="attributes.foo" default="true">
<cfparam name="attributes.foo2" default="false">
<cfset xfa.success = "goTeam">
<cfset xfa.failure = "boo">
<cfinclude template="qry_findthis.cfm">
<cfinclude template="dsp_generatethis.cfm">
<cfinclude template="tmp_showthis.cfm">
<cfinclude template="url_return.cfm">
</cfcase>
- 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.
- 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.
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.
IOW, qry_findthis.cfm would return variables.fuse.qryFindThis instead of
variables.qryFindThis. I'll have to think about that a bit.
> 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 makes sense, but using the attributes scope doesn't make sense.
> The idea is that all of the fuses have a single scope that they use to
> pass values through.
I'll say it again... it's pretty amusing, the multitude of ways human minds
can analyze identical situations. At some point, we all read Steve's basic
ideas, and different people came up with:
- "We use Attributes for custom tag compatibility."
- "We use Attributes because someone mistakenly thought custom tags couldn't
see the Form and URL scopes."
- "We use Attributes so we can have a central repository of
request-generated variables."
- "We use Attributes so that our fuses can pass values through a single
scope."
I'm surprised we ever manage to convey useful information to one another at
all. [g]
> I think we're basically in agreement and this has boiled down to
> semantics.
To a degree, yeah. After all, it won't *hurt* anything to support scopes
other than Attributes in FU2A.
--
Roger
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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
