Thoughts, ideas, tips, musings, and pontifications (not necessarily in that order) by Ben Forta ...
NOTE: This is my personal blog, and the opinions and statements voiced here are my own.
What is the advantage of doing everything in script? I know it looks more like a "real" program and gives people the warm fuzzies, but what is the real advantage?
Ben - I would not say it's the only reason. One real problem with writing components is they tend to be very verbose. I think that this is going to cut that down and make my life easier.
Tag syntax is seen as a barrier to entry for developers used to script-based programming. Many CFers also prefer script-based syntax but have been unable to leverage that in CFML due to the limitations in the past. So Ben's right and Dan's also right :)
I've been writing my components in script wherever possible for a couple of years now but the limitations really chafe and I still end up dropping into tag syntax for a few methods in each component which is really annoying.
I may be in the minority these days with respect to people reading/posting blogs etc but what are we exactly getting by making making cfml cfscript compliant? Just a mere hope that developers from other languages will be attracted. I personally doubt it. Do we think that we can allure groovy/jython/ruby developersby these enhancement or prevent existing cf developers from migrating to those languages by adding few syntactic sugar? Believe me - as a long time cf developer - these are the questions bothers me personally. I always admired cf for its simplicity and plain leaning curve. Just as proof, see the # of blog post on cfinterface after cf8 release and then compare those to CF8 ajax features.
I am definitely in the "YAY TAGS" camp. However - as Sean mentions - they *are* a barrier to entry for people coming from the likes of PHP and unable to see the benefits of them.
Hopefully, having a complete set of cfscript syntax will attact those people first to CFML (for its many other benefits), and then we can further assimilate them into the tagged way of thinking.
Of course, for existing CFMLers who have gone over to the terrible world of excess braces, I'm not sure what can be done for them. ;)
john, you haven't used PHP, have you? There are *many* benefits of CFML over PHP - the functions there are horribly inconsistent, there is no concept of datasources, mappings, Application scopes, and so on.
If you have contractors, they should be working in-line with your company's coding standards, whatever they might be.
I think the biggest push for cfscript isn't just to bring in developers but also to keep current CF developers from opting for other languages that have more concise and powerful syntax. I think it is time to look at groovy/ruby/python for inspiration towards the future of the primary language used in CF and let tags live on for templating and page based development.
--- Ben
I've been writing my components in script wherever possible for a couple of years now but the limitations really chafe and I still end up dropping into tag syntax for a few methods in each component which is really annoying.
< cfquery > and < cfoutput > are great examples. You can't get any easier and more productive than that.
I have not seen 1 example of these 2 tags in cfscript that makes it easier or more productive not to use them.
However - as Sean mentions - they *are* a barrier to entry for people coming from the likes of PHP and unable to see the benefits of them.
Hopefully, having a complete set of cfscript syntax will attact those people first to CFML (for its many other benefits), and then we can further assimilate them into the tagged way of thinking.
Of course, for existing CFMLers who have gone over to the terrible world of excess braces, I'm not sure what can be done for them. ;)
I'd hate to now have to spend extra time with juniors because one contractors does all his work in cfscript etc
one or the other and only one
There are *many* benefits of CFML over PHP - the functions there are horribly inconsistent, there is no concept of datasources, mappings, Application scopes, and so on.
If you have contractors, they should be working in-line with your company's coding standards, whatever they might be.