The Future of ColdFusion Part 2

Word Count: 368
In my last article we looked at some things that Adobe is doing to further the advancement of ColdFusion. In this article I want to take a sneak peak at the next version of ColdFusion (CF 9) currently code named Centaur. First we are going to look at a series of language enhancements that will help build a better ColdFusion.

The first is to fill in the gaps with cfscript. One of the ideas behind this is the ability to write your components just using cfscript. I blogged about this awhile ago and I am really happy to see this enhancement. I know others have told me (or commented) that they are not a big fan of this and my answer to you is OK. This will change nothing in your day and you will still be able to write you components using tag syntax. What this does do is provide another solution for those of us who want to use it. I understand that declarative syntax makes things a heck of a lot easier for us but it also adds tons of typing. Creating components for me is going to get a lot quicker with this new feature. Adam threw up a slide and the code looks like the example below. While this is not the most logical code (I know its just an example) it does look sweet. He also added that passing methods will be fully supported.

The next enhancement was the new explicit local scope. Anyone who has written a component knows that writing private variables is kind of "weird". Right now you have to use the var keyword and you have to set it at the top of your function. The var scope is where the weird comes in because it is like no other scope in the language. There is no collection for the var scope like there is with session or event the arguments collection. Moving forward you are going to use the local keyword to declare private variables and the good thing is that the scope can be used throughout the function. For your existing code that does use the var scope ColdFusion will auto magically place those variables into the local scope. Staying with that theme they may add a feature to set a default scope for a component. We have all come across memory leaks in a component that usually come from a variable not being declared private to that function. With the new feature you will be able to tell the component that the default scope is local and if a variable is not declared it will be set into that scope. I don't have any inside information to how the syntax will look but here is and example of what our new component could look like. The nice thing about this example is we could eliminate the need to declare a scope for our query name. This has always frustrated me because I can think of no situation where I would want that variable to be anything but private. If another method has to access the query there are much better ways to go about it.

Next the cfcontinue and cffinally tags are going to be added. The continue just allows you to break a loop and jump back to the top. In the past we would usually write some kind of if/else statement to get out and go back now we can just use cfcontinue. The finally tag will always run after a catch. This is pretty common among other languages so its a welcomed addition. The one thing that Adam brought up that I thought was kind of cool was that cfcontinue is already a part of cfscript and will be the first method to ever ported from script to tag.

Next is the addition of the new & import keywords. The new keyword will allow you to create objects with very little sytax. With that is the addition of the import keyword which will allow us to treat our components in more of package format. Along the same lines is Implicit constructors. Right now everyone just kind of follows the guideline of using the name init as a constructor. With this though you usually have to call the constructor, in the future this will change. There are a couple ways we can go about doing this. The first is sticking with the init name so that code we created before will still work. Next we can use the name of the cfc, so if our component is users the function users will be our constructor. Finally we can tell the component what method to use as the constructor by defining it in the component by saying <cfcomponent init="name_of_constructor". If we look at the code below you will see it makes it easier to create objects.

Next Adam started off by saying that this was long overdue and he was right. Implicit getters/setters will be a great addition and cut down on coding value objects. By using the cfproperty tag and setting accessor="true" we will know that there are getter and setter methods for the property. The important thing to note here is that its not generating code for you, that object will just implicitly have the getter and setter methods. Also if you already have getters and setters it will use your methods and ignore the implicit ones. Here is a quick example of what our user component might look like.

Next is the new Server component. This component will be defined per instance and contain a couple of handy methods; onServerStart & onServerEnd. All application components will inherint from the server component. The next two actually need their own post. Any comments on any of these exciting enhancements are welcomed.

Comments

#1 Posted By: Jeff Gladnick Posted On: 6/22/08 7:33 PM
Am i the only person with no desire for further cfscript capabilities? To be perfectly honest, I kind of prefer the tag based syntax to cfscript, and it definitely makes it easier for new people to read your code. Learning MG, Coldspring, and OO is difficult for newer programmers coming into the fold, but having to learn new syntax from scratch makes it even more difficult.

Sometimes it seems like coldfusion is having an indentity crisis, where being tag based is a huge plus , and then other weeks everyone seems to lament limited cfscript support.
#2 Posted By: Dan Vega Posted On: 6/22/08 7:42 PM |
Author Comment
I absolutely understand where your coming from with this. At the same time though remember that there are people who would like the option. As I said there will be no change for most developers but for some its a welcomed enhancement. I personally don't use cfscript at all right now because of the lack of support for tags and always having to use the script blocks. Once there is full support you might have a different outlook on it.
#3 Posted By: Dan Sorensen Posted On: 6/23/08 3:13 AM
Within a cfc, I prefer cfscript! I like the tags when I'm working on an output html template. Since I'm using a lot of javascript now, the cfscript is getting easier to work with.
#4 Posted By: duncan Posted On: 6/23/08 4:27 AM
<cffunction name="q">

??
#5 Posted By: dfguy Posted On: 6/23/08 8:15 AM
the cfscript enhancements are kewl, the only thing is that you can't call tags within cfscript. unless they create equivalent functions for each tag to be used in cfscript, i don't see the point.
#6 Posted By: Dan Vega Posted On: 6/23/08 9:14 AM |
Author Comment
I think that is the Idea behind bridging the gaps with cfscript. I am pretty sure they fully plan to support cfscript in v9
#7 Posted By: Dan Vega Posted On: 6/23/08 9:16 AM |
Author Comment
Sorry, fixed the typo.
#8 Posted By: Sean Corfield Posted On: 6/23/08 1:16 PM
For a long time I was an advocate of deprecating cfscript as a waste of effort - duplicating existing language features instead of spending time adding new features. Since CF8 added a number of small cfscript enhancements, I've found myself using cfscript more and more and I use cfscript to write the public portion of components where possible so I'm loving this announcement about being able to write all components in cfscript.

Also with the ability to pass arbitrary attributes to tags now, it's trivial to write a tag-based wrapper function for arbitrary tags and then invoke that from cfscript (Adam showed a good example at cf.Objective() for invoking (cf)mail from cfscript).
#9 Posted By: Sean Corfield Posted On: 6/23/08 1:17 PM
p.s. Comments do not work on your blog in Safari - it rejects every captcha text.
#10 Posted By: Dan Vega Posted On: 6/23/08 1:19 PM |
Author Comment
Great points Sean and thanks for the heads up with Safari.
#11 Posted By: Adam Cameron Posted On: 6/23/08 4:46 PM
Hi Dan
Man: this is all very interesting news. For the longest time I've wanted more "investment" put into enhancing CFScript, which seemed to be an unpopular position, certainly the opposite of a lot of people whose opinions I value.

This made me stop and think about why I was so dead keen on CFScript as opposed to tags.

My position now is that both have their merits:
- tags make the most sense when doing HTML integration / interaction, especially when the tab encloses other text (possible HTML, but not necessarily) to be processed, eg: CFOUTPUT, CFQUERY, CFMAIL, custom tags etc.

However on the other hand, I think it's "wrong" to use a tag for something like CFFILE, CFOBJECT and stuff that doesn't have a closing tag, and for which a closing tag would be meaningless. Basically those tags which are doing "y = f(x)": performing an operation on some values to reach an end result. I don't see how it makes sense for that to be a tag.

(Actually thinking about it, CFFILE is actually a sitter for having a closing tag, wherein the contents of the two tags is what's written to file. Alas it doesn't do that).

Hardly any of the code I write interacts with HTML, so I really don't see tag-based code being the best fit for the work I'm doing.

Obviously for other people, doing lots of HTML stuff, tags are perfect for a lot of operations.

I'm pleased Adobe are doing more work on CFScript.

Tell me: if they're doing CFFINALLY, are they also doing a plain ole "finally" statement for CFScript too?

Speaking of finally... @Sean... interesting to hear your change in position on this.

Cheers.

--
Adam
#12 Posted By: Dan Vega Posted On: 6/23/08 4:49 PM |
Author Comment
Very good stuff Adam and I agree with you on when and where I would use tags/script in the future. I do not speak for Adobe but I would have to think if they are adding the finally tag that it would be supported in script as well.
#13 Posted By: Sean Corfield Posted On: 6/23/08 9:33 PM
Adam said finally "may" be added to cfscript just as cffinally "may" be added to CFML tags.
#14 Posted By: Dmitriy Goltseker Posted On: 6/26/08 3:07 PM
I just would like to add that developer's background needs to be considered as well. If someone came from c++/java, etc background, they would prefer to use cfscript. New developers, who usually start learning HTML, would prefer using tag-based code.


Post Your Comment

Leave this field empty







Show Captcha

If you subscribe, any new posts to this thread will be sent to your email address.

Copyright © 2007 Dan Vega | BlogCFC was created by Raymond Camden. This blog is running version 5.8.001.