Welcome to the seventh entry in the Intermediate ColdFusion Contest. The earlier entries may be found at the end of this post. Today's entry is from Jason Fill. Before reading on, please check his application here. You can download his code from the download link at the bottom. Please respect the copyright of the creator.
The first thing I noticed was how the page updated. It was obviously DHTML (or AJAX, or whatever you wanted to call it), so I dug a bit into his code. I'm going to cheat a bit and make my writing a bit easier by quoting his docs from play.cfm:
As you will see below, the doRequest() function is the main JS function that is called. Basically, that function dynamically writes JS code to the page by using the create element method. So we call a specific function based on what we need to do, for example if the player wants to hit, we call the playerHit() function which sets the the actual page we want to call, then from within the playerHit() function we call the doRequest() function to create the element on the page. When the element is created on the page it actually makes the call to the url that we set in the original function playerHit() and that does the page rendering behind the scenes. If you look at the template that it calls playerhit.cfm. You will see all the code that works behind the scenes to perform the actual player hit. Then at the bottom of the page you will see 2 additional function calls - updatePlayer() and showTable().
Very good job on the documentation. (The text above is only a small portion.) This is the JavaScript code he is talking about:
function doRequest(url){
// this is the core of all the functions. It will make the request happen
// create < script > element
var js=document.createElement('script');
// assig n < script > attributes
js.setAttribute('language','javascript');
js.setAttribute('src',url);
// append element to document tree & send GET request
document.getElementsByTagName('head')[0].appendChild(js);
}
I've never seen anything like this so it was pretty interesting. If you take a look at one of the files that serve as a response, you will see that he generates a large string and saves it using cfsavecontent. He then performs some formatting on it for JavaScript, and updates content on the main page. A bit complex - but I think you have to admit that it shows up nicely. I can say that I find the dealer's turn a bit too quick. I sometimes got confused as to what happened, as it seemed as if while I was reading what he just got dealt, another card would be dealt as well. This was also noticeable when I got 21. The game automatically made me stay, which makes sense, but it just felt a bit weird when playing. From an organizational stand point, I'd probably consider moving the "server" files to another folder, just so it is obvious what files act as "servers" to the JavaScript.
Now for the bugs. I was able to confuse (and break) the application by hitting back after I my bank was empty. The game reported I had (25) in the bank, which I suppose is it's way of reporting negative 25. After I tried to play though it just kind of hung there.
I also swear I saw the dealer stay once on 16 - but I didn't see it happen again.
As with many other submissions, his CFC doesn't use var scoping. (Yes, I'm getting to be a bit crazy about it, aren't I?)
Earlier Entries:
Archived Comments
> As with many other submissions, his CFC doesn't use
> var scoping. (Yes, I'm getting to be a bit crazy about it,
> aren't I?)
As well you should. Var scoping sucks, and I think we all prefer other languages in which variables defined within a block are local to that block, but its a necessary part of CFC development. Besides, its better to start the var habit NOW rather than later. Who wants to go through thousands of lines of old code adding "var" over and over?
Seth,
I disagree. Javascript, ActionScript, and Java, require var scoping. Let me inform you that Java is the most used language in the planet, CF is number 19. I particularly like the control of choosing whether the variable should be local or global. CF should not make that assumption. You should be glad and thank Macromedia for adapting this from Java and giving you the freedom and control over your code.
IMO
-Rob
I'm with Seth on this one.
In Java, don't you use the var keyword to declare a variable for it's usage? In CF you do not need to declare a variable before using it; that is the benefit of a loosely typed language. Because of this, the var keyword seems like a huge kludge.
JavaScript (also loosely typed) operates much like CF does in this regards, except you can use the var anywhere in the function (it doesn't have to be at the top). JavaScript, however, is loosely typed.
I don't know enough about ActionScript to make a statement about it, although from what I hear about AS3, I suspect it is leaning towards the Java implementation.
Back to CF, I don't understand why variables are not local to the function by default. I don't understand why we can't use the var keyword whenever we create the variable. Why does it have to be on top?
I also do not understand why local variable don't have a scope that exists during the function execution (why use the var keyword at all)
Jeff,
I'm with you on 'must be at the top'. I do not understand the reason behind that... Should be anywhere, just like JS/AS...