Johnny, Technically, yeah, that's exactly right.
If you want to see all your scopes and all their contents, try this: <cfdump var="#getPageContext().getBuiltinScopes()#" /> That will dump every built-in scope, or those available to any page, special tag scopes notwithstanding, including: cffile cgi variables session application server form url client The other scopes, primarily, are (be kind, workin on the fly from memory here!): cfhttp cferror/error (similar but different, depending on cferror tag settings, see docs) query (addressed by queryName) cfcatch arguments parameters super thistag caller The first list are *always* available to any page, CFC, or construct of any type. The "variables" scope is the default container for any variables declared without being explicitly scoped in your code. So you're correct... args is actually variables.args. There are reasons to collect your form and URL vars into variables.args, though... it's a lot more convenient and allows you to build to an interface (i.e. args.action can be URL OR form, not restricted to either, doesn't matter which) rather than building to an implementation (MUST use URL or FORM, dependent on one or the other). You can use structAppend(args,url) and structAppend(args,form) to accomplish this, and the order in which you do this or whether or not you use the overwrite flag for structAppend is determined (in FB and MachII, and by developer choice in ad-hoc) by a variablePrecedence flag of form or url, determining which you know you can depend on to be in the args struct if there's a name conflict. All pages and CFCs have a variables scope and access as mentioned previously. However the other scopes, in the second list, are only available to code executing within the same context as the tags that create them (i.e. cferror is only available on an error page). So, if they occur within a function, they're available to the CFC. If they occur in a page, they're available to the page. If they occur in an include, they're available to the page after the include but not before. If you need to make the contents of a query scope that is created inside a CFC available to a page, you're going to have to use CFRETURN or cfset to a session, application, or some other mechanism to pass the query scope to the calling page. The other scope is the local scope, or the var scope, or function-local, that being a variable that dies as soon as the function in which it was declared, finishes executing... And, by "context" I basically refer to the owner of the current variables scope. Calling #args.maxCount# from within a container (like a page or a CFC) will, by default, refer to variables.args.maxCount. That's sort of what this thread is all about... is it acceptable to rely on the default scope for calling variables. Anyway, I hope that helps... J On Sun, 27 Mar 2005 23:43:05 -0400, Johnny Le <[EMAIL PROTECTED]> wrote: > This sounds great, but isn't the args variable has its own scope too? It is > variables scope, isn't it? Since it declares locally in the function, I am > not sure if its scope is variables, but it has a scope of something. So if > you have scope everything, you would have to do variables.args.MaxCount, > right? > > Johnny -- Continuum Media Group LLC Burnsville, MN 55337 http://www.web-relevant.com http://www.web-relevant.com/blogs/cfobjective ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Discover CFTicket - The leading ColdFusion Help Desk and Trouble Ticket application http://www.houseoffusion.com/banners/view.cfm?bannerid=48 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:200188 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
