ColdFusion 9 and the onTap Framework

I'd like to say that every upgrade is as seamless as the upgrade from ColdFusion 7 to 8, where I didn't have to do anything (that I remember). But of course they don't always turn out that way. Back when Macromedia released ColdFusion MX, myself and a number of other developers had to do a fair amount of work to remove references to structure variables named "this". It turns out that they've added a "local" scope in ColdFusion 9 and wouldn't you know, about the time I stopped using "this", I started using "local" instead. ;)

Ryan McIlmoyl gave me the heads up on the issue on the DataFaucet list. About a day and a half later, I've just finished up the basic modifications for CF9. (There were 3.5-thousand references to "local" in the core code, plus another 500 or so in the Members onTap plugin, with plenty of false-positives.) I don't actually know if the onTap framework is still working on CF9 yet, because I haven't installed it to test with yet. If you give it a shot, let me know how it goes for you.

One thing I'm glad of though, is the way I designed the ontap.cfc. This is a component with some basic functionality that was created before onMissingMethod() was added to the language, otherwise it might have looked a bit different. But in essence, the lack of onMissingMethod() is why the ontap.cfc has generic getters and setters (or accessors and mutators for you lingophiles out there). These are two private methods name getProperty() and setProperty() and two public methods named getValue() and setValue() instead of having loads of individual functions named getBlahBlah() and setYaddaYadda(). What's cool about this arrangement is that in all my CFCs, nowhere to I directly reference the structure that holds property values, which was named (you guessed it), "variables.local". Well, nowhere except in about 3 private methods in ontap.cfc. And because all my other CFCs faithfully relied on getProperty() and setProperty() instead of simply referencing local.x or local.y, that means I only had to change "variables.local" in about 3 places. This saved me HUGE headache. If I'd gone the other way and used all hard-coded (or more to the point hand-coded) getters and setters, I'd have had easily another couple thousand references to replace and another day's work on this update for CF9. I love it when a plan comes together! :)

I was actually thinking about this the other day too, because I was looking at a small application someone else wrote (I won't mention any names), where they used all hand-coded getters and setters in their code and I was trying to figure out how to use it for configuration. After about an hour or two of looking through the code for documentation of one of the features I realized that said feature was never completed. There were just 23 references to it hanging out in the code, not doing anything at all (other than passing a useless variable around). All those 23 references were mostly hand-coded getters and setters, plus a couple of form fields and param tags. And I was thinking to myself, how nice it is to know that, for the most part, that sort of thing doesn't happen in my applications. Sure I make mistakes, everyone does, but the point here is, if I'm writing config for an app, there's not going to be 23-lines of code hanging around for a single config value, there's probably going to be about 3 or 5 and that means not only less maintenance, but less work up-front as well. :)

So new zip archives of the core framework and of the Members onTap plugin are up on RIAForge.

Comments
Brian Rinaldi's Gravatar My understanding of how the new local scope works is that if you had a cfc that used a structure called local like that, it would be local.local and there wouldn't be a conflict. Is this not the behavior you saw?
# Posted By Brian Rinaldi | 10/20/09 9:31 PM
ike's Gravatar Hey Brian, well... the problem then would be that the code in my cfc is referencing local.x instead of local.local.x and apparently the server becomes confused at that point. I only know because one of the guys on the DataFaucet list posted a note saying that it was failing on CF9 and mentioned the local scope. So I updated all the code for the ORM framework and put up a new version and he said all his unit tests passed with the updated code, so that's my source. But I haven't actually seen it directly because I haven't installed CF9 yet.
# Posted By ike | 10/21/09 12:28 PM
ike's Gravatar My suspicion is that it sees the line where I set var local = structnew() and has no problem creating the structure, and maybe it's fine if I set it to an empty structure but I think that in a few cases I had set it to a non-empty structure, like var local = getSpecialStruct() and then when it attempts to fetch local.x out of that struct CF goes to the local scope instead of the struct and doesn't see the variable declared there.
# Posted By ike | 10/21/09 12:35 PM
BlogCFC was created by Raymond Camden. This blog is running version 5.5.006. | Protected by Akismet | Blog with WordPress