Patrick -
The problem with not using any scope is that if you have a local variable
with the name "myvar" as well as a one in the form scope, things get
overwritten. Therefore, it's a good idea to prefix any variable with it's
scope, not just leave CF to do it's ordering thing.
NAT
> -----Original Message-----
> From: Patrick McElhaney [mailto:[EMAIL PROTECTED]]
> Sent: Friday, March 23, 2001 7:18 AM
> To: Fusebox
> Subject: RE: Musings on Attributes (was Best Practices...)
>
>
> I've put a lot of thought into it, and have come to the conclusion
> that we don't need attributes.
>
> The idea behind "attributes" is this: We combine all of the scopes
> into one so we don't have to specify the scope a variable originated
> from. But that's no big deal, because Cold Fusion does that anyway.
>
> If you leave out the scope, CF checks all of the following scopes in
> the specified order:
> 1. Local variables created using CFSET and CFQUERY
> 2. CGI variables
> 3. File variables
> 4. URL variables
> 5. Form variables
> 6. Cookie variables
> 7. Client variables
>
> The only problem I see with this is if you want to use fusebox as a
> custom tag, you can only access the parameters passed through the
> attributes scope. The designers of Fusebox decided to tackle this
> problem by putting *everything* in the attributes scope, whether
> the circuit is being called as a custom tag or not.
>
> It seems to me that it would be easier to go the opposite direction,
> by copying all attributes scoped variables to locally scoped
> variables. But then you run into encapsulation problems. Local
> variables in the calling template aren't available to custom tags,
> but URL & FORM variables are. Still not a major problem because
> FORM and URL variables will never override a variable scoped
> locally within a custom tag.
>
> The only problem is if I want to check for the existence of a
> local variable. The variable may be present in the form scope, but
> not the local scope, causing my isDefined("") function returns true
> where I expect it to be false. The same problem happens with CFPARAM.
>
> However, I've done some reasearch and found a workaround for that.
> Cold Fusion has a default scope for local variables (called "Variables")
> and that's the first scope in the list that it checks. So if I
> write <cfset x = 1>, CF interprets that as <cfset varibables.x = 1>.
> And I can verify that a variable exists in the local scope by
> checking 'variables.x' instead of just 'x'.
>
> In order to make this work properly, we would need to make sure all of
> our FROM, URL, and ATTRIBUTES variables are copied to the "variables"
> scope (CF_FormURL2Variables?), but we could leave off the scope when
> referring to our variables, except when we are checking for their
> existence.
>
> Patrick
>
>
>
>
>
>
>
> 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
