> Patrick,
>
> Not in my methodology. Any given member of the attributes structure is
> touched (at most) one time... when it is copied in via FU2A in
> app_globals,
> or when it is CFPARAM'd into existence within a single CFCASE.
That's interesting. Maybe there's something in your methodology that I
can use. What do you do when you need to create a parameter in one
fuse and pass it to another?
> Hm... your comment has me wondering about something, though. How common is
> the practice of changing the value of attributes during the
> processing of a
> fuseaction? Are people out there routinely adding things like XFAs to
> attributes, or treating the scope as a central repository for "Fusebox
> variables" of all kinds, including those that are modified on-the-fly?
Yes, I do that all the time. I've always assumed that's the way everyone
does it. In fact, I think I go a step farther than most people. If I
query for a single item in a database, I'll actually copy the results
to attributes variables. (i.e. attributes.firstname = qryUsers.firstname)
And if the query returns multiple rows, I'll just copy the entire query
to the attributes scope.
> If so, I can kind of understand where some of the confusion and opposition
> is coming from... although for the life of me, I can't understand
> why anyone
> started doing that in the first place.
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. And the same scope is used to pass values into the
circuit in the first place. Just as control starts with the index.cfm
and is passed back to the index.cfm after each fuse executes, the values
start out and are passed back to that shared scope.
> > If it's important to you to know if a variable came from outside
> > the fuse (a VERY, VERY bad idea, IMHO, because a circuit isn't
> > supposed to know about its environment), you still have the
> > original, untouched FORM, URL, and ATTRIBUTES scopes.
>
> Using three distinct, incoming scopes cripples the custom tag powers of
> Fusebox. That's unacceptable for my uses.
No, you're missing the point. Those three are all copied to the variables
scope (in my methodology). Whether the circuit is being used as a custom
tag or a stand-alone app, it will find the parameters it needs in the
variables scope. It doesn't need to worry about FORM, URL, or ATTRIBUTES
to function.
> And no matter what you do, there is *some* point where your circuit has to
> ask questions about the environment... even if it's just at the
> point where
> you copy the form, URL, and attributes scopes into Variables.
I think we're basically in agreement and this has boiled down to
semantics. I still think we need an abstraction layer (FormURL2Attributes)
to copy the information from URL/Form/Attributes to Variables, but that
abstraction layer insulates the circuit from its environment.
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
