Brad asks:
After studying open sourced Coldfusion applications, I have noticed Coldfusion experts use cfscript, mostly for functions, create objects, and take advantage of Java language. I wonder why do they often use cfscript and what situations are they useful?I hope I don't sound egotistical if I include myself in that group of experts, but let me give you my own personal feelings on this. I don't actually use cfscript very much. Not to say I never use it, but I'm just not a huge user of it. I'd disagree that people use cfscript a lot of functions... or at least I'd urge against it. While it is useful for simple UDFs, remember that tag based methods give you control over the output, access, and other bits of metadata that you would need, well should use, for defining your methods.How can I go around and learn how to use cfscript?
Also, you certainly do not need to use cfscript to take advantage of Java methods. Tag-based CFLM works just fine with that.
So what situations would be useful for cfscript? If I'm doing some quick prototyping and using some simple statements, then I'll consider using cfscript. For example:
<cfscript>
x = 1;
y = 2;
z = x+1;
</cfscript>
But as you can see, that is very trivial code. I can say that with the planned enhancements to cfscript in CF8, I may use it quite a bit more. Like others, I've gotten tripped up by the use of < and > in cfscript so I may start using it more when I do production work in CF8.
As for learning cfscript, you can always try the documentation: The CFScript language
Archived Comments
I generally agree with you here. I used to use it a lot and I now don't use it at all. Too many unsupported tags forced me to hack my to making scripts work or keep opening and closing script blocks.
I would say that at this point I am perfectly comfortable with the tag based syntax. There is less noise in cfscript but other than that it offers no real benefit. So, despite the updates to cfscript in 8, I probably will stick with the tag syntax personally.
I find cfscript very useful when writing large chunks of set and if statements. It seems faster, you're not encumbered by typing a large number of characters that aren't needed (tag names primarily, such as <cfset> and using if() rather than <cfif>).
Given that conditional loops are supported in CF7, there are even fewer reasons to use cfscript. That was one of the few flow-control features that script had which CFML didn't.
Brad, one reason why you may see a lot of UDFs written in cfscript out there on the web is that when UDFs were first introduced in CF5, they could only be written using cfscript. It was only from CF6 onwards, that you could (and should, for the reasons Ray mentions) use tag-based syntax.
Actually line for line, the reason is because cfscript is faster (performance wise) then cfset.
Here is the post on it:
http://www.nomachetejugglin...
There is an tutorial on CFSCRIPT here on House of Fusion
http://www.houseoffusion.co...
As for speed, the gap between CFSCRIPT and CFSET/CFIF/etc. has closed with the latest versions of ColdFusion.
I prefer it because of so much less clutter, but I'm stuck in old habits and still most often use tags now.
From previous threads on this, I'd say the majority of "experts" in the CF world seem to prefer tag based syntax. The reasoning varies from "it's easier to keep straight tag based CF from Javascript and AS" to "so many tags aren't supported in CFScript, it's easier just to use CFML across the board" (which is - I believe the most common response and used to be my position.)
That said, I find now that I use CF Script almost exclusively. Almost all of the tags that CF Script is missing (cffile, cfquery, etc.) I tend to wrap in methods so that I have a single touch point for modifying how queries and the file system operate (i.e. I'm not doing this just to be able to use CF Script - I'd do this even if I coded entirely in CFML). There are some tags I miss such as cfdump/cfabort, but a quick dump() method added to my base class (hey, it's my framework - so if I want to throw in a couple of base methods, so be it!) and I can dump(whatever); anywhere I want - even quicker than the cfdump/cfabort, and I find the lower amount of noise (which is in the end of the day the main benefit of CF Script now that I believe it usually gets compiled down to the same byte code with possibly a couple of exceptions) is a good reason to use it.
There is really no good reason to use a tag based syntax for a general purpose programming language (although if it floats your boat don't let me stop you :->). A tag based syntax works really well for a templating language for generating dynamic HTML (which is what CFML started out as), but for methods in your model or controller, I've never seen the point of the extra noise.
That said, there is a lot of preference involved in this. If you know CFML and don't find the extra few characters annoying, I'd stick with it.
Yes, I use CFScript. A lot. No, I haven't gone so far as to write wrapper functions for tags not supported by CFScript, but I use it heavily for business logic processing (if this set this) and looping constructs. There was a fairly recent blurb on the CFWeekly about a shop that had a page that used the cfloop tag, and the same page with the loop in script. Upon decompiling the actual java class files it was discovered that they were different (BTW, the script was faster). Somebody actually had benchmarks posted at one time (Dave Shuck maybe?) that seemed to suggest script was faster as well.
I tend to use it for economy of code, less lines of processing, and typically only code blocks that don't have output. Example: we have a home rolled trouble ticket system for submitting client issues. We have several scheduled processes that do various tasks, like auto-escalating 'high' priority tickets to 'emergency' status after 48 hours. This typically involves a few gateway objects running different queries, usually within a loop. No output, no user interaction, no fuss, no muss, and runs fantastically as a 'scripted' application.
I think that some of the performance gains we might see now, with CFScript, will probably be a thing of the past with Scorpio. From the reports of the UG Tour (Nashville tomorrow night!) things appear to be much faster, and I imagine that the Adobe engineers have re-engineered the base java classes of most tags (to utilize the new features of Java 1.5, and probably common code base between tags and their script counterparts). That being said, I'll probably still use CFScript a lot, and see it as a natural transition for a JavaScript or ActionScript programmer moving into ColdFusion (and good experience for a CF programmer writing more JS and AS).
I think using <cfscript> over CFML is fine as long as the developer is consistent in their usage of it. I've reviewed too much code where the developer flip-floped back and forth between the two (most of the time for no good reason), which made readability less than favorable.
Personally I favor CFML for the simple fact that it has access to all of language features, like locking, which I'm not sure can elegantly be accomplished with a wrapper under <cfscript>.
I started out as a designer/HTML guy and one of the things that drew me to CF was the tag-based syntax, which I find much easier to understand than the script syntax.
So for people like me who are still trying to learn new CF stuff from the "experts", it IS frustrating to try to decipher code examples that have a lot of cfscript. For example, I've learned a lot CF "theory" from reading Peter Bell's articles/blogs, but it's so much work for me to try to figure out some of his code.
The way I look at it, why should I have to learn a whole new way of coding? If I wanted to code in "script" syntax, I would've taken up PHP! ;-)
Hi Tony,
to be fair, the way I code, even if it was in CFML it might still not be that obvious :-< If there's anything you have a real problem with, comment on the article and I'll do what I can to give a sense of what it'd be doing in tags!
Thanks, Peter. Reading my post again it looks like I was picking on you, but I definitely didn't mean to (you're still one of my favorite "experts"). Actually I was agreeing with your earlier point that it's really just a matter of preference. Code that is "cleaner" and "less cluttered" to some might not seem so to others.
Next time, I'll make sure to ask you if I get stumped by any of your code again and maybe I'll (as Ray puts it) learn to stop worrying and pick up a little cfscript!