Migrating over to ColdFusion 9 and some things that have tripped me and maybe you too
Tags: ColdFusion 8, Coldfusion, ColdFusion 9
In the last few months I have been slowly migrating our Application over to ColdFusion 9, I already knew some of the sort comings but some of them well caught me off guard.
The number one thing I have learned was that with any version, you should always scope your variables. Don't think for a moment that if you take the shortcut of not putting variables in front of your variable that it will work either. ColdFusion 9 introduced a new scope called local, that just seemed to cause some very weird issues with us.
One of the very new features to ColdFusion 9 was the fact that in our functions we now have the scope local, this was to provide developers with a way to create variables that is local to the current function. This actually caused us some extremely weird issues, which the most had been due to un-scoped variables.
I have always been an advocate to scoping your variables and yes I will say that even I can fall into this trap as the next guy, but the reality is that if you want to make your Application future upgradeable then the number one thing you should do is fully scope every single variable.
ColdFusion 9 and the cfgrid tag
This is the one area that has caused us the most trouble with ColdFusion 9, and this was not because our code was wrong. But because Adobe changed the behaviour and didn't give older Applications I thought on this.
The very first problem our Application experienced was any code that added images to the header columns, the code behind the scenes had changed so that we had to change the single quotes and the double quotes in our Application. This was not a big deal, and was fairly easy to modify and get working but if you didn't know about this you would be left wondering and cursing Adobe for not having proper integration and unit testing in place to combat this sort of change.
The next problem our Application had was with the column headers themselves, Adobe just added the ExtJS library and either thought to themselves that nobody would ever mind if they just left the default configs. This broke our application even further to the point that we decided to remove any need of the cfgrid features altogether, and thus eliminate any future possible breakages on this.
I have posted on the past about these problems and Adobe just couldn't have cared less, my advice to anyone who uses any of the UI features of ColdFusion, think long and hard about the future of your application and whether you can afford your client or even your company spend money to fix the problems these UI components have introduced.
We found things like cell alignment, sorting just totally broken in these grid and we rely on these in our application. And this was enough for us to say enough if enough, and look at another solution.
So be warned, and use these features at your own risk.
ColdFusion 9 and the CFAjaxProxy tag
This is also another issue that I have blogged on, and at the end of the day(OMG I here my boss talking to me) if you have used this in your application there is a huge gotcha on this as well. I wont go into the full details, but rest assured that the behaviour of this and the Application scope is totally broken in ColdFusion 9. This is also another area the I am currently looking at writing to make something just as good and work, no matter how many versions we upgrade to of ColdFusion this factor will also be removed from the equation that ColdFusion can't break on us anymore.
If you require a fix for this if you do need it in ColdFusion 9, then see a previous post on this issue.
ColdFusion 9 and the new local scope
Before ColdFusion 9 the best practice to creating local variables was to use something like this:
This believe it or not has caused me the most grief when converting our application, because in ColdFusion 8 this would actually equate to variables.local, but what if we had a variable setup like this in ColdFusion 8?
<cfset local.session = 'test' />
In ColdFusion 8 this would actually create the variable like variables.local.session, however in ColdFusion 9 this would not be the case. And for some unknown reason that only Adobe can answer, is that it would create a scoped variable called local.session, but it would also trash and delete anything in the session scope at the same time.
Adobe have warned that using reserved keywords is something we should not do, but the question we have to ask is well why did it work in ColdFusion 8?
So rule of thumb on this issue is that we should get ourselves knowledgeable on what keywords not to use, and we might not run into this problem.
Another issue that I ran into was with method names, if the method name was the same as anything that was in the local scope we ran into problems, so the following code also failed.
<cfset local.myTask = myTask(arguments.someVar) />
I have no idea why this actually failed but it did, and it should be something that one really should take into consideration that if you are going to name a variable the same as any method in the component then expect that this problem will exist.
Last but not least was as I stated earlier about scoping your variables, this has been the biggest headache I faced in this migration and it is something that I am sure will cause a lot of issues in the future as well.
Lets take the following code?
<cfset var q = '' />
<cfquery name="q" datasource="something">
// query to load data....
</cfquery>
<cfquery name="local.q" dbtype="query">
select columns
from q
</cfquery>
Now the thing here is that what we need to consider is that with the local scope and the variables scope, is the order that they are searched in. The problem here is that in the second query there is an un-scoped variable, in ColdFusion 9 this would mean it searches through the scopes till it finds q, which means the local.q scope.
This ended up causing corruption of variables in our Application, and although I don't agree with the problem it highlights the fact that we as developers should always scope our variables.
Conclusion
I didn't find that many problems migrating over to version 9 of ColdFusion, but if anything I can't say it enough.
Always scope your variables.
Read: Migrating over to ColdFusion 9 and some things that have tripped me and maybe you too: In the last few mon... http://bit.ly/ggEGw3
Jan 6, 2011
Migrating over to ColdFusion 9 and some things that have tripped me and maybe you too - http://cfbloggers.org/?c=46748
Jan 6, 2011
-
A few problems/questions about your post.
1) You say, "One of the very new features to ColdFusion 9 was the fact that in our functions we now have the scope local, this was to provide developers with a way to create variables that is local to the current function". This seems to imply there wasn't a way to do this before CF9. You may not have meant that - but to be clear, there certainly was a way (by using the var scope). Local is simply meant to be a formal way to reference there variables.
2) cfajaxproxy: You say, "but rest assured that the behaviour of this and the Application scope is totally broken in ColdFusion 9". I'd really like to see details on this. You seemed to imply you already blogged it. Can you share the URL?
3) You say: "Before ColdFusion 9 the best practice to creating local variables was to use something like this:
<cfset var local = {} />
We can argue on that. I'd say best practice was to always var scope. Using a local sctruct was just something some folks liked. To me, it was too much extra typing. But i fully expect you and I (you and anyone else) to not agree 100% on what is best practice.
4) You say, " because in ColdFusion 8 this would actually equate to variables.local, but what if we had a variable setup like this in ColdFusion 8?" This is incorrect. While I did not use var local = {} myself, I worked with code that did. It never wrote to the variables scope. Period. I'm willing to stake my repuation on that - or maybe I'm simply misreading what you mean. But cfset var something=something never wrote to the Variables scope of the CFC.
5) You said, "And for some unknown reason that only Adobe can answer, is that it would create a scoped variable called local.session, but it would also trash and delete anything in the session scope at the same time." Let me focus on the first part. This is not "some unknown reason." The docs clearly state that the local scope was added to CF9 and is supposed to be equivalent to using var something=something. You seem to imply this was some random change where in reality it was planned. I knwo it tripped some folks up - but it wasn't random. ;) As to your second part, I'm going to try to recreate it. Did you log a bug report for it?
6) To your code sample where you do var local = q - was that a typo? If you are writing _new_ code in CF9, you shouldn't do this. It would be like doing url = 1. url is a built in scope, as is local in 9.
# Posted By Raymond Camden | 1/6/11 7:15 AM -
As just an FYI, I wrote a CFC that used local.session. See:
component {
remote function foo() {
local.session = 2;
return local.session;
};
}
I then wrote this CFM:
<cfset session.name = "ray">
<cfset res = new test().foo()>
<cfdump var="#res#">
<cfdump var="#session#">
I am not seeing the session scope get overwritten.# Posted By Raymond Camden | 1/6/11 7:18 AM -
Ray,
1) It does imply that, and you are right. I should have made it clearer that it was a new scope that was introduced in ColdFusion 9
2) Very easy go to December 13th post 2010
3) Well I was the one who also used to use var scoping, and found that many started to use var local. This is what my current job uses as I know many do, so true both are best practice.
4) You are right I didn't mean to imply that it wrote to the variables scope of the cfc, but in all intents and purposes it is a variable that is local to that method.
5) ok if we go by your definition on the local scope, that means it is still not behaving the way it should either.
Here is what I do know, because we had this in our code.
var local = {}
var q = {}
then we would create a query into the q variable, then we did a QoQ like this
<cfquery name="local.q" dbtype="query">
select *
from q
order by subject, dtDateTime
</cfquery>
What I found here, was that the code here failed. And it failed because the local.q ended up trashing the var q. Once I scoped the above query like this
<cfquery name="local.q" dbtype="query">
select *
from variables.q
order by subject, dtDateTime
</cfquery>
It all worked fine again.
6) I think you should re-read the post title, and that might answer you question here.
# Posted By Andrew Scott | 1/6/11 2:15 PM -
Ray, I can't explain your example what I can say is that our Application had something like this setup somewhere in the Application.
<cfset session.config.name = 'something' />
In our Application when we went to reference this in code something like this
<cfset local.session = 'here' />
<cfset local.temp = session.config.name />
An error was thrown, this error was very simple and it basically said that the variable session.config.name didn't exist or had not be defined. We all know that message.
So when I did a line debug through the code, I watched the variables and saw the session exist as a scope before the local.session was being set and then watched it disappear after that code was run.
# Posted By Andrew Scott | 1/6/11 2:23 PM -
Quick comment before I reply deeper later. I had (or thought I had) clicked "Subscribe" but I never got emails.
# Posted By Raymond Camden | 1/7/11 6:52 AM
-
That is right you did, the problem is that while moderation is switched on subscriptions don't work.
I asked you about this once before, so if you have fixed this I haven't upgrade your code, I am not far from releasing the site running on a new Application.# Posted By Andrew Scott | 1/7/11 2:37 PM
TweetBacks