Application Name Gotcha - Case Sensitivity
You may have read one of my previous posts regarding the nuances of working with Application Variables. In the first post I took great pains to point out that the application name is the anchor for all the variables in the application and that naming 2 separate applications the same results in them sharing the same scope. Now, thanks to Jim Davis of Depressed Press I have another "gotcha" to add to the conversation.
Try this little test. Create 2 folders on your CFMX server named "\A" and "\B". In both folders create a single template (it doesn't matter what it contains) and an "application.cfm" file. In the application.cfm file put the following code.
Application "A"
<Cfif NOT isDefined('application.testvar')>
<Cfset Application.testVar = 'GoodBye World'>
</CFIF>
<Cfdump var="#application#">
Application "B"
<Cfif NOT isDefined('application.testvar')>
<Cfset Application.testVar = 'Hello World'>
</cfif>
<Cfdump var="#application#">
Now, open up the "A" folders template in your browser. In the dump you will see the testVar is "Hello World". Open up the "B" folder and you will see (as you no doubt expected) that the testVar is also "Hello World". That's because it is set in "A" and the CFIF keeps it from being reset in B because it has already been pre-defined in A. Still with me?
Change the Case of "B"
Go to "B" and change the name of the application from thisIsMyBlog to ThisIsMyBlog (in other words capitalize the "T"). Then open both folders again. What you will see is a major inconsistency in CFMX - which, like the Johny Fairplay of Ap servers, claims to be be case in-sensitive. As far as I know, any other variable that you set in CF will be case in-sensitive. Only the application name appears to be case sensitive. Mixing case in your application name will create an entirely different scope.
Why should it matter you ask? After all, wasn't the point of your previous post that the name of the application is an important item and should be unique? Well, that depends. There are some creative ways to use the application framework that depend on having applications of the same name. Such applications would share a set of "base" variables and other settings would "cascade" down from there. This may be more difficult to maintain, but it can also be helpful in certain cases. For example, when you want to migrate data sources. Changing 1 file sure beats changes 15 different application.cfm files - and keeps your data in synch. The problem is that if you are not aware of the case in-sensitivity issue you could run into a devilish problem where variables are not changing when they should - and it would be very difficult to track it down.
8 Comments
-
But this is nothing to do with the case *in*sensitivity of variable NAMES. This is about the *contents* of a variable. I don't see why anyone would be surprised that a value of FOO and a value of foo are not considered equal for the purpose of naming an application. I would have been extremely surprised if the application name was *not* case sensitive. Are you saying that was the case in CF5? (I never used CF5 so I don't know) -
Sean - If I do "foo.bar = 1" and "foo.Bar = 2" the value of foo.bar is now 2. Why is not the same when I set application.applicationname (or this.name in application.cfc)? I understand what you are saying - internally the routine that sets up the application has some sort of hash table and evaluates the "contents" of the name attribute against other application names present. But the CF developer's exposure to the "name" of the application as it relates to organizing code and applications is that it's the value of "application.applicationname". And to most CF developers from the windows world (me at least) if one application.applicationname is "foo" and the other is "Foo" I would expect the behavior to be a shared scope - not 2 scopes. Either that or it should be a clearly documented behavior and couched as one that "might surprise some of you out there" :) -
Sean - sorry... I missed that CF 5 comment. On CF 4.x or 5 the application name "contents" is case in-sensitive. I put the sample code here:
http://dev.cfwebtools.com/tmp/a/
http://dev.cfwebtools.com/tmp/b/
To refresh either use a url param called refresh as in:
http://dev.cfwebtools.com/tmp/b/?refresh=true -
At first I thought the reason you could do "foo.bar = 1" and "foo.Bar = 2" and have it come out as 2 was because under the hood CF is capitalizing the structure key "foo" in the variables struct. But then I tried
<cfset variables['foo'] = "this is foo">
<cfset variables['FOO'] = "this is FOO">
And it still works. So yes, as far as I can tell this is the only place where CF applies case-sensitivity to a variable name. -
Brian,
Yes - I just think it's inconsistent, or at least to nuanced to remain undocumented. -
Just to be clear (again):
foo.bar and foo.Bar are variable *names* as are variables['foo'] and variables['FOO'] - and I would expect those to be case insensitive, so we all agree on that.
The name of the application (not a variable) to me ought to be case sensitive but if it wasn't in CF5 then I can see why long-time CFers might be surprised by this.
If you feel that CFMX should treat cfapplication's name as a case insensitive value, you should file a bug:
http://www.macromedia.com/go/wish -
Fix it? And have this lovely well-written blog entry go to waste? (ha) Your point is well taken and I get it - the "name" of the application is not really a variable. I just think it's a gradation of meaning that's probably lost on most folks. In any case, the next time someone pops up in CF Talk or some other list and says "I'm having trouble with my application name" I have have a number of resources to point them to - mostly thanks to ya'll :)
-
Another place where variables is case-sensitive. When using variables with cfsearch name collection and cfschedule tags.
<cfset lstCollections="coll_A,coll_b,coll_C">
<cfsearch criteria="testing" collection="coll_a,coll_c">
will give us inaccurate results.
Sites to Watch
Aggregators
RSS
