CFSCRIPT – The little language that …

November 18, 2007

To quote Ben Forta in 2004: “<CFSCRIPT> today is in a strange place. ” ( I don’t think much has changed in that regard. The fact is, Macromedia ColdFusion stopped partway through the metamorphosis of becoming a scripting language. Kind of like stopping part way through a sex change; the important parts are there, sometimes both sets, and it can be ugly to watch. Now it’s in Adobe’s care, and there are more than just PHP and ASP wandering by and looking at CFSCRIPT, with a mild sense of relief (glad that’s not me) and perhaps a bit of Schadenfreude.

I’ve read articles about Coldfusion programmers jumping ship and running to Ruby on Rails, I wish everyone the best voyage possible, whichever boat they sail. I spent years coding C++ as a plugin to Netscape, to serve up web pages. Then Apache Server. Coldfusion looked like a treat from that vantage point. Despite it’s imperfections, it is a powerful way to make many web applications happen very quickly. That doesn’t change the fact that CFSCRIPT could never run on it’s own. It’s incomplete. Like Pinnoccio, always needing Gepetto around to keep working on him, and no Blue Fairie coming to turn him into a real boy. Yes, CFSCRIPT is in a strange place, and it will likely see out its days in the place that it is.

There is an almost audible sigh of relief that escapes when entering a block of logic which won’t be needing html tags or CFML to make it do it’s job. But eventually the lines of code free of the greater than and less than signs is brought to a screeching halt by one of those things that cfscript just cannot do properly, or requires the esoteric approaches of the guru to get through.

I noticed Sean Corfield’s scripting plugin post, basically allowing a Coldfusion 8 developer to plop in some PHP here, some Ruby there. (a moody person could write alternative verses of PHP and Lua, bringing a Wagnerian feeling to the code). A colleague has been telling me about Groovy, and its possibilities and I stand intrigued. Something will have to yield, one way or another. For things CF could not handle, I used to opt to extend CF with C++ CFX tags. Now, with CF being Java based, it is cleaner to extend with Java (my opinion). Can Groovy solve some problems that CFSCRIPT could not? Is it compelling enough to justify a significant effort in that direction? Groovy and Hibernate play well together (supposedly). I may do a little with Groovy’s Gant (to get past the Ant XML build structure), but beyond that I don’t know. Groovy is too new for risking on my customers, for the time being. But what the future holds, I cannot tell.

As for the rest, I am grateful for having had the chance to work with all of the languages I have. I wish every programmer could have a wide exposure to languages in that way. I feel the same way about natural languages (written and spoken and signed-eg. American Sign Language). The more one can learn about other languages, and their inherent approaches to solving problems, and their implications, the better one can understand and utilize their home language. And though I make fun of different computer languages, I enjoy working with them a great deal.

After doing some work with Lex/Yacc for preprocessing of some code, I did some experimentation with the problem of carrying the cfscript language the distance, by adding “real” classes, to replace the tag based cfcomponent artifact.    Then, adding to that some special system classes that could yield database connectivity and scaffolded views, and cfscript is more complete, operationally.  None of this changes the fact that  CF is locked behind a webserver, and there is no past nor any future for CF based console apps or desktop apps.  It is a backend database application server for the web, when it is doing what it does best.

It is difficult *not* to conclude that Adobe (and perhaps Macromedia) purposefully prevented the completion of the ColdFusion CFSCRIPT “language”.  And given that, it would be interesting to understand exactly why, though one could guess that they don’t want to be a big player in that marketspace, to distract their focus from other more interesting areas.  For the developer who continues to hitch his career on ColdFusion, I would admonish them to add a few additional tools into their toolboxes.


Get Outta my namespace (revisited)

November 18, 2007

Earlier, I discussed some of the problems/issues with Flex Builder’s default configuration of outputting the swf into the “bin” folder. (see Get Outta My Namespace). Operationally, the dot Net server’s claim to the “bin” folder in server root context was one of the roadblocks to use of the “bin” folder. It’s easy enough to use another name, to avoid conditions like this one.

Well, I was recently concerned with the performance of a web application, running on IIS on the JRun4 J2EE server distributed with ColdFusion. I decided to try running the application on a JBoss server, with ColdFusion 8, and do some performance benchmarking, and analysis, to see if the problem’s root was in JRun’s management of the memory objects, or in the tuning of the JRun server, or if the change in platform would make a difference at all. The performance problem is likely rooted in the application’s architecture, and the database configuration, but it was worthwhile and easy enough to see if there was any difference in changing the platform this way.

I have a JBoss 4.05 Server running Tomcat and ColdFusion 8, basically following the easy instructions at Steve Brownlee’s blog when I had first set it up with ColdFusion7, then updating it with ColdFusion 8, using the advice from Adobe. When I attempted to use the Flex application deployed in a “bin” folder which was *not* in the root, that is it was several subfolders away from the root, the server acted as if the html container and the swf file were simply not there. I tried several things before eventually simply renaming the deploy folder to “out”. Immediately, the server recognized the deployed html and swf. I haven’t yet determined what exactly is going on, but I know the bin folder has various application specific uses for JBoss and Tomcat. It seems as though this is interefering, once again, with the default “bin” folder output for Flex deployment. I’ve updated the project, locally, to build to “out” and mapped the application to “out” and it is all working just fine.

As for benchmarking performance, I have started. I’ll try to post anything interesting I might find.