> As noted by Ray, in the comments of my first blog post, the Variables > scope was kind of an afterthought, giving a way to access those > variables that weren't explicitly in another scope (form, url, session, > application, request, client). With most of the core of ColdFusion > created prior to it's port to Java, or even the thought of OO web > application development, I think that many of the scopes kind of came > about as an afterthought. Containers, of sorts, to fill specific needs. > The Variables scope always existed, it just didn't get the "VARIABLES." > prefix until MX (if I remember Ray).
I'm pretty sure that the name "Variables" predates MX by at least two versions. The Request scope was introduced in 4.x, primarily for Spectra if I recall correctly - Spectra had a lot of custom tags, and passing variables back and forth from custom tags to their callers is a bit of a pain. I wouldn't be surprised if "Variables" has always been available as a named scope, and I'm pretty confident it was in CF 3 (which introduced CFML custom tags) - I remember it being in the official Allaire course curriculum. And i don't really think that the Variables scope itself is an afterthought - it's the default scope, and for a long time it really didn't need a name to separate it from the non-default scopes. > *The following is deduction, conjecture, and opinion. Discuss freely if > you wish, this is just how I see it.* > I think that usage of the Variables scope, on a high level, was never > well documented. That years and years of examples and sample > applications were written without really thinking about what the correct > usage of the scope might be. The Request scope, by it's name, appears to > be where you would place variables to be used throughout a request. The > Variables scope operates very similarly, until you declare them inside a > custom tag. A custom tag can directly access a Request scope variable, > but Variables declared outside that tag are invisible (without using the > CALLER scope). From a timeline perspective, this is important, because > custom tags predate cfc's, which have the same constraints. It's very simple - I don't think a lot of conjecture is needed. By default, when you create a variable within a page, it's only available within that page. Before CFML custom tags existed, this wasn't a problem, as there wasn't anywhere else you had to worry about; when you CFINCLUDE one page within another, for all practical purposes you end up with one single page at runtime. But custom tags execute separately from your page - your page halts when the custom tag runs, and restarts when the custom tag has finished running. And CFML has been consistent about this behavior, really. CFCs are separate programs, just like custom tags, so they have their own separate local variables that are referenced using the "Variables" scope. Functions, on the other hand, are not separate programs, they're embedded within your page (either literally, or via CFINCLUDE) so they share the same Variables scope - and need their own specific function-local scope. > My theory is that Variables were to be used within custom tags only. The > problem being, custom tags were just .cfm templates with no way of > explicitly declaring them as custom tags (outside of how they were > called), and as such any .cfm page could 'do' Variables. I don't think that theory is borne out by history. > As I put in the second item above, I think the use of the Variables > scope, outside of it's encapsulated usage within a custom tag or a cfc, > is a mistake. I think it was something that ultimately shouldn't have > been possible, and once it was discovered as an issue it was too late to > change behavior because of the thousands of applications that would have > needed to be refactored. Ugh. No. In general, in any programming language, you want to use the most restrictive scope possible. If you're only going to use a variable within a single page, and not within any custom tags, there's no reason not to use the Variables scope. There's no reason to refactor applications that are doing this. If you're going to use a variable within a page, and you also want that variable to be available to custom tags, then sure, use the Request scope. The key lesson isn't to use Request instead of Variables, it's to know the difference between the two and use each appropriately. > I can say this: poor performing CF apps can generally be greatly improved by > scoping all variables, paying heavy > attention to the db (queries, indexes, execution plans, etc), and tuning the > JVM for the application in use. In my experience, the performance improvement you get from scoping variables that are currently unscoped is not usually worth the time to change the application. If you've done things the right way from the beginning, great - but I've yet to see the application where (a) this hasn't already been done, while at the same time (b) the database on the other hand has been perfectly tuned. Also, you left out caching - the single biggest performance enhancement in my opinion. Out of those four items, scoping is almost insignificant. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ http://training.figleaf.com/ Fig Leaf Software is a Veteran-Owned Small Business (VOSB) on GSA Schedule, and provides the highest caliber vendor-authorized instruction at our training centers, online, or onsite. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Order the Adobe Coldfusion Anthology now! http://www.amazon.com/Adobe-Coldfusion-Anthology/dp/1430272155/?tag=houseoffusion Archive: http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:344725 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
