Use CFArgument For… Everything
In my new effort to rid my life of global variables, I’ve been focusing on the arguments scope. I think the arguments scope is the key to solving this problem.
With my MVC-CFC framework I find it is easy as pie to live without global variables. In a nutshell, EVERYTHING is passed in through a <cfargument>. No more request scopes for me.
It takes a little more work to do this, but in the end I think it’s worth it. The cfarguments help validate the data and ultimately make auto-unit testing fairly simple to do by calling the getMetaData() function. I’ll post more about that another day.
So for example. I used to name my datasources with #request.dsn# I’d set the variable in some settings file, then use it directly in my cfquery tags. Now it takes a few more steps.
1) Instead of the request scope I use the arguments scope and set it in a file that is called with every request (such as Application.cfc).
2) The controller methods have a cfargument.
3) The controllers then call the model methods, the dsn is passed down to the models, each of those model methods ALSO have a cfargument.
4) Finally it is used in the cfquery:
What do you think?
Btw, I KNOW someone is going to focus on my dsn variable instead of seeing the bigger picture. If you want I can use variable names of “foo” or “bar”. CS students LOVE this layer of abstraction. I think it’s an awful way to explain programming. So, I beg you, before you tell me how you deal with datasources, see the forest through the trees. This isn’t about datasources, it’s about global versus local variables.
-Steve Nelson
Hi,
I think its more a overhead and putting extra efforts to pass extra parameters.
Ahhh another famework in market (MVC-CFC framework), if your approach makes developers life easy then welcome …!!!
Thanks
Comment by Sam — January 22, 2008 @ 12:00 am
Arguments have more overhead than what? Are you guessing or have you actually tested this?
It’s not technically a framework in the market in that it’s nothing more than a series of ideas. I proposed about a year ago that, when organized, CFCs themselves ARE the framework.
Comment by Steve Nelson — January 22, 2008 @ 12:00 am
I remember seeing your presentation at our user group, and it seems like a really nifty idea. I wonder if the Allaire guys had any specific goals when they originally envisioned cfcs.
The one "bug" I really wish they’d fix though is that optional arguments still show up in the iterator, they’re just null. So if you use an optional argument and don’t provide a default, cflooping over the arguments collection will still show that key, as will structKeyArray() and friends, but structKeyExists() returns false! So in the end you need to use structKeyExists() inside the loop if you plan to use the arguments collection.
This especially gets nasty when you try to do something like getTransfer().listByPropertyMap("Object",arguments)where the arguments are by name, but optional, since Transfer explodes when it hits a key that doesn’t exist. :/
Comment by Elliott Sprehn — January 22, 2008 @ 12:00 am
Whoa, that’s really odd.
CFCs are the framework solution we begged for years and years ago. I do remember sitting with some Allaire engineer with nat and hal, i think it was in Disney world. They were like "what do you think we should add?" I said, "You guys should make custom functions (at the time they were cfscript) into a CF tag! That would be much better" I was so impressed with myself. Of course it was probably Hal or Nat that said something like. "How about adding objects?" Well, duh. That was a little more important.
Comment by Steve Nelson — January 22, 2008 @ 12:00 am