Posted in ColdFusion | Posted on 02-03-2009 | 5,965 views
Just sharing a little picture Adam Lehman (aka adrocknaphobia on Twitter) just shared via twitter:
Notice the editor name? Notice the code? Question is - if you could write 100% of your CFCs in script, how many of you will? (I know I will!)
Hey - why not make a survey about it Ray? Duh!
I appreciate programming languages like flex, java, c# etc, but i bought/use CF so i dont have to write strict language OO code.
And is that CF9 ORM code I'm seeing?
ColdFusion has always been billed as Rapid Application Development. Why slow it down? How important is it that we look more like java?
q.setDatasource("cfartgallery");
q.setSQL("select * from art where mediaid = :mediaid:");
q.addParam....
Um, no thanks.
<cfquery name="q" datasource="cfartgallery">
SELECT *
FROM art
WHERE mediaid = #mediaid#
....
</cfquery>
I do enjoy scripting in OO (i.e. ActionScript), but for simple pieces of code - like a simple SELECT query (which should be a SP anyways), old school CF code is perfect - clean, elegant, simple. I'm sure I will use some scripting in the new CF, but definitely not 100%. Not even close.
The whole point of Coldfusion is being able to write web apps fast, but when I have to write large-scale apps that need and benefit from code reusability, .Net wins out because of the editor. (I also prefer using cfscript for the ecma-style syntax)
If CF9 gives us proper intellisense features in the editor, this will go a long way toward building reusable code in CF.
I really like writing cfscript, and it allows for a more rigid syntax, which is great.
It's like the difference between Windows/Linux or SQL/MySQL. Linux is more strict, and when you program for it then you end up with much better code (at least in my opinion)
var q = <cfquery>
SELECT *
FROM foo
WHERE (a = ?)
</cfquery>;
q.queryParam(1, 'a', 'VarChar');
P.S. - I answered this question in May 2007:
http://rickosborne.org/blog/index.php/2007/05/09/c...
Wherein I said:
"
if Adobe came to me tomorrow and asked me the following question, what would I tell them?
We’re going to release a new product: the ColdFusion engine and capabilities (easy queries, easy App/Session/Client management, etc) but you can now code in server-side ActionScript/JavaScript/ECMAScript. You get all the fuzzy wonderfulness of ECMAScript 4, including variable typing, E4X, lots of literals, anonymous and first-class functions, etc. But, we’ve gone in and added bindings for every part of the infrastructure, so there’s nothing you can’t do in this new language. You’d be writing your CFM pages and CFCs in this new language instead of CFML. Interested?
Essentially, it’s cfscript on steroids, instead of the semi-afterthought that it is now.
"
Can I get commission on every sale, thanks to my proof of prior art?
(I kid, I'm a kidder. No, wait, not kidding. Yeah, I am. No.)
As long as there is some sort of "heredoc" syntax (a generic form would make more sense than a special case for certain tags) to allow multi-line string collection, the query code they have above is fine. <cfsavecontent> is my #2 favorite tag, BTW. Creating large multi-line strings is a nightmare in languages with only simple concatenation.
But you did bring another question to my mind. I'm all for making cfscript capable of doing everything cftags can do, but let me ask this: Will cfscript be able to "embed" cftags? What's the script-equivalent of the <cfscript> tag itself? I tend to switch between the two methods, but I love the tags for things such as <cfquery> and <cfargument> because the tag/attribute representation seems more expressive. If I'm in the middle of a <cffunction> and hit a long string of variable manipulation, I'll switch to script. But if I start in script, or I'm working in code someone else wrote in script, will I be able to "opt out" and go back to tags for a section?
The worst thing that could happen with this is if people who code primarily in one method are thrown into code written the other way and suddenly feel like they need to learn a whole new language.
I only wish thy addopted the same syntax as ActionScript, oh well perhaps version 10 enhancements.
But it would be good hook to get ActionScript Flash / Flex people to pick CF as the backend.
<cfquery stuff here>
select *
from art
where mediaid = <cfqueryparam ...>
</cfquery>
Looks awfully similar to me. Err, I mean in size of course, not syntax.
I am NOT in the camp that thinks CF _needs_ a 100% compatible script version to survive. But after working in Groovy the past few months, I am definitely IN the camp that will switch to script based CFCs if they are added to CF9. Once you go script, you don't go back. ;)
Both could be written on one line, but of course, we wouldn't do that. We MAY do that more with the CFML version, because we have the luxury of being able to space the query any way we want - that is to say, with more complicated SQL (and I personally deal with some complicated stuff) I'll space it and comment in it for the sake of future maintenance.
My main point was that it introduces complexity - logical steps in the building up and executing of a SQL statement that CFML was made to overcome in the first place.
I'm sure the ASP/PHP/JAVA community will love it ;-)
And - I wouldn't say it is just ASP/PHP/Java folks. You also got Flex/Flash/AIR folks using scripting as well.
Again - I was definitely in the 'tags are fine' crowd - but after working a while in scripting only environments (Flex/Groovy), it's amazing how used you get to it.
I see where they are going with this based on flex/AS3 Flex Builder experiences. You have your tags and you have your action script. People are comfortable with it, and it works. However, you can do one or the other or both.
So, it looks like Bolt and cfscript are taking a lot from Flex Builder. I do believe this is exactly what we asked for.
My only hesitation with going back to script-based syntax is that old temptation to start thinking about web sites like a programmer again. The revolutionary vision of CF was to help you design your site using the same thought process the visitor has. It led to much more interesting, innovative, and usable sites, IMHO.
The curse of wanting to be like everyone else is just getting your wish.
/ejt
I would not mind writing other parts of the CFC in script though.
Makes a lot of sense to define the params outside the actual query.
1. It's much easier to see when you haven't queryparam-ed a variable
2. For those queries where you have to include the same queryparam many time, you just have the one definition, which you can refer to multiple times
3. Makes the query much easier to read.
The reasons for CF always were a low entry barrier, ease of use and RAD. With ActionScript, you have none of these. It would make CFML just more complicated.
Use ActionScript or Java or what else, where it makes sense. But, if you turn CFML into a clone of another language, then what reason would there be not to use that other language instead of CFML? I really think this would do CF (and it's market share) more harm that it would do good.
Since they are already introducing a script format, why use a java syntax when they could use an ActionScript format, its just a barrier to ActionScript people and confusing if you go between CF & ActionScript a lot, like we do.
For example
public query function getData(mediaId) {
public function getData(mediaId):query {
Its not that different, but different enough to be annoying.
If they were clever, and we know they are, the will support both, this will please the java people and the ActionScript people
Im sick of explaing that a component is a class.
So they could easily support both
component
{
or
class
{
You cannot achieve the simplicity of CFML with AS-based syntax. And CFML and it's simplicity has been one of ColdFusion's unique selling points.
I agree that it may be more convenient for some developers not to have to change the coding style between a Flex application and a CFC. But, that's just a personal preference.
I also agree that the tag based syntax is just an abstraction. If there was no need for these, then why is there something called MXML?
In the past we read things like "write a database query in CFML and in Java and compare the amount of code". CFML is designed to make things simple. No need for things like prepareStatement() and executeQuery().
These abstractions make it easier to write applications. If I do queryNew() + setDatasource + setSQL() + addParam() + execute(), that's five commands instead of one tag. And there goes the easy-factor that comes with CFML.
With the new syntax CF code will look just like Java code (or PHP, or ASP, or whatever). And if it's just the same, then why should someone choose ColdFusion over any other language? (I know that CF is more than just a language, but, the new developer making a choice might not know.)
And the advanced folks that write blog entries and examples and tutorials will use the new syntax, because it is possible. And that may very well raise the entry level barrier for new developers that depend on these things.
I know I would not have started with CF if it had been the same as with Java. The argument that caught me was "but it's so much easier with Cold Fusion" (spelling intended ;-))
It's almost the same as with the return types vs. "duck typing" discussion some time ago. CFML still is not a strong typed language and there is no need for CFML to be like AS.
cfawesome.
<cffunction ... >
<cfargument ...>
<cfscript>
...
If I can make it even cleaner I'd love to.
You have to admit, cfqueryparam is an abomination when it comes to readable code. Having a bunch of angle bracket things in the middle of my well formatted sql drives me nuts.
344 votes.
213 (63%) for
131 (38%) against
I guess that's why javascript can be a struggle for me sometimes - I have to mentally translate these into a pseudocode that is more "English-like", and I have to avoid getting tripped up over those punctuation syntax.
That said, I can adjust. It'll just take me a little longer to find the bugs in cfscript code . . .
That query looks an awful lot like VBScript for my tastes.
CFScript has its place, but it's not as easy to pick up for newbies. CF thrives on ease of use and rapid development.
i think most people will agree that it's not the syntax of cfscript that they don't like, it's the fact that you couldn't do cfquery or cfsavecontent in cfscript. so you would have to do out of it when you needed to use these tags.
also from what i see in the screenshot writing a query in cfscript is WAY different then it's tag counterpart. they should have just implemented blocks into the language and this would have help keep at least the syntax of cfscript close to the tag based syntax.
totally awful in my opinion.
But, ok, 3 vs 5 lines...times a complete application. 66% extra coding, are you saying that this is the one and only section of coding that will produce the extra "bloat" when it comes to script vs. CFML? Is there trade off? Is the scripting faster? Is it easier to debug? Does having MORE lines of code in an application reduce the law-of-averages chances of there being a typo or something out of place that cases QA problems? Or is it just there because the code monkeys are too snobby to use something that is easy to do? Is the "power" of a language/framework defined by how "cool" it is to CODE in, or how good a developer feels when they do something very complicated with lots of syntax that another developer has to fawn over to see "how'd you do that?"
Maybe it is, but that's not my bag, baby. But, hey, if it negates the "I don't like all those TAGS"/"Its not a script/procedural/blah blah language" arguments from the anti-CF crowd, then have at it. BUT, if you come into my team, scripting CF, you better damn well have an absolutely amazing reason to do so, because my applications are complex enough as it is, and using CFML allows us to concentrate on the business problems, not the coding problems.
Cheers,
Davo
Also, you are picking on -one- aspect, the query. Notice how return types and access attributes are specified? That's _less_ code.
I'd be willing to bet we could go through and find some cases where you type less and some where you type more with tags versus script.
I think it is rather presumptuous of you to imply that those who want scripting enhanced are only doing it to be cool or snobby. Maybe they just _like_ it and are more productive? If you and your team are more productive with tags, then sure, stick to it. But don't assume it's just the ruby/cool/whatever crowd who will want/use this new support.
Again, using just myself as a personal example, I've found that scripting is _enhancing_ my workflow, not making it any more complex. I will definitely use this _where appropriate_ in my applications.
I want to work faster, and more efficiently, and for my own personal experience, cfscript just doesn't cut it. Perhaps its personal taste, but I just find it easier to read the tags, and easier to teach new people the tag syntax vs cfscript. I REEAALLLY dislike the idea of forking the language. I can figure out cfscript but its slower, and it might as well be another language - Why not just use java as the backend if you really want to just cfscript - this is practically what we're getting now.
I know a lot of folks seem to want cfscript, and some of them are quite vocal! But I hope Adobe keeps in mind the rest of the community before shouting all aboard the CF Script train.
My biggest fear: Half of the open source CF apps released will be completely in cf script, and the other half in tags, confusing new people and making the modification of said programs that more difficult.
When you say "I'd be willing to bet we could go through and find some cases where you type less and some where you type more with tags versus script." - could we? Hey, that would be great. In all of the scripting languages I've worked with (a little PHP, some Java and mostly ASP), I've never seen it, but maybe Adobe has found a way to do it.
I'll admit I'm being presumptuous - but that mostly comes from my experiences with those outside the CF world who sneer at the product and people who use it. They look down at a "tag" based syntax as being for the kids - let the grown-ups script. I know, I'm SOOO sensitive! :-)
I could go on for hours about these situations with other development platforms - I personally witnessed IT departments remove development platforms that end (business) users LOVED, but developers/managers didn't consider it a "real" programming language. That's just so you know, I'm not making these statements in a vacuum, they are decisions I've seen made, and arguments I've heard presented in real life over the years. None of them were valid arguments.
Of course, script should be used where necessary - but that wasn't the title of your question. You used the "all" keyword, a blanket statement, and thats what I, personally, was replying to.
It's an interesting debate though, and I'm sure if anyone can bring me around it's the Jedi himself ;-)
Cheers,
Davo
(p.s., yeah, that last part was a big expectations set up on my part, muhahahaha)
I for one welcome our CFScript overlords.
public query function getData(...) public is the access and query is the return type.
"Of course, script should be used where necessary - but that wasn't the title of your question. You used the "all" keyword, a blanket statement, and thats what I, personally, was replying to."
Well, I said all _CFCs_, not all CFML. Again, I can see using scripting for the model layer (which is normally all CFC) and tags for the view layer (which is normally all CFMs).
As for bringing you around... all I can suggest is trying it. When you can of course. ;)
There is little question that cfscript syntax is more difficult to follow for newbies.
While it seems silly to say Adobe should _not_ do this (having options is great, to each his own, etc.) I can definitely see how this could have a negative impact as well.
Adobe does a pretty poor job of promoting this product, which means much of that burden falls on the shoulders of this community. When newcomers - or just plain entry-level to intermediate CFML developers - search out to find out how to do things, they will be seeing a hodge-podge of code examples with less uniformity than before. I suspect that this will confuse and discourage a large group of these developers.
I guess the balancing act is how much writing CFML in script, or script+tags, enhances the productivity of some in this community versus how much in confuses an alienates others in this community?
Still, I'm waiting for the compelling reason to use script, other than "I can" (I script, therefore I am???). If there were performance gains by using script, now THAT would get my attention. Whether it be ALL applications, or ALL CFC's, I'm still looking for that reason.
As for trying it, I'm sure I will, as will my minions! If they present a compelling reason to use script, then we'll definitely go with it, and hey, you never know, I may be back on your blog scolding you for not using script enough!
Cheers,
Davo
public var mediaid
mediaId is the input, like <cfargument>
q.getSQL(@"
SELECT *
FROM table
WHERE ID = 2");
That would make the SQL a lot more readable. Hopefully the CF guys will think of doing this.
s = "
This is a multiline
string in CF. CF ROXOR
"
The only thing you have to watch out for is escaping your quotes, but SQL shouldn't have quotes in it anyway. ;)
I am saying is that, come CF9, online blogs, tutorials, articles, will now have the same thing done two different ways. Which in some ways, could prove confusing for someone looking to get into CF.
var q = new query(dsn="cfartgallery");
That'll save you one line right there :) Or you could pass an entire argument collection and be done with it.
My thought on this came from the <> button in the toolbar, suggesting tag view. I could be wrong, but this would seem like a great way of allowing scripting in ColdFusion.
So stop asking for scripting support in a tag-based language, or start using a scripting based language and quit Coldfusion if that's the major thing your missing in the language.
491 entries.
Yes (300 or 61%)
No (191 or 39%)
ASP.NET has tags and PHP is commonly used in a tag like manner in the presentation layer (Joomla templates for instance). Maybe it is not binary and the two can co-exist and used where it makes sense. Tags in the presentation layer and script in the model. You know, "two great tastes that taste great together"? Options are good and could lead to a *gasp* broader audience for CF.
Besides ppl are going to have to learn JS sooner or later and CFscript can provide a great lead in for JS.
Whether you use script or tags, CF still has a powerful engine behind it that you just don't get with JSP. The language is just the interface to the engine, be it tags or script.
Cheers,
Davo
I've never been a fan of the script syntax, so CF has literally been a godsend.
Hey Rey! How about displaying the results of your poll? Or am I missing that somewhere?
WilGeno
no but seriously... why all the fuss? it's not like <cfcomponent> and <cffunction> and <cfargument> are going to stop working.
if you like script-based syntax, you can write your CFCs in script now. if you don't... nothing changes. all this does is add the option. more options are "a good thing", right?
For people that have moved onto breaking their code into model/view/conroller, they will probably understand script enough that an open source project in tags or script will be easily understood. This is the qualm, right? Open source and existing projects splitting into model code based on 100% tags or 100% script ?
Huh... I think that I will port one of my apps and write the front end in all CFScript and do the model using just tags. And then post it to RIAForge. You know, just for the WTF factor.
I get the opinion, that CFML is to "script-coders", as the Flash "timeline" was to developers in general. So, would having the option to code "All" (or any) CFC's in script appeal more to Flex developers? I'd imagine so. It certainly wouldn't be to the detriment, that's for sure.
If that is the case (and I'm assuming Adobe did their homework on this), it would place CF closer to Flex and AIR, and present it as the best product to use as a back end for these applications.
That could seriously grow the user base for CF, especially if CF9 has tighter Flex/AIR integration (I can only speculate it will). I think most of us would agree that an increasing significance in CF in the marketplace is good for all of us.
Just MHO.
Davo
In our development I could see a use for scripted business logic components and cftag'd DAO components.
ie.
resultSet = daocomponent.getResultSet(arg1,arg2);
(where daocomponent uses <cfquery> tags)
I was fairly ambivalent about the whole BOLT/cfscript news. Until I realised that with a scripted approach there is much greater scope for code-time introspection+validation (ala Flex Builder). This can only improve the coldfusion coding experience.
I also don't get why everyone is so gaga about an editor... I like textmate, works fine.
on a UI note, ray you might want to highlight the error fields on these forms, took me like 3 times to realize I didn't enter "http://"; into my website.
..and notepad, works fine.
But I get gaga about developing Java in IntelliJ and ActionScript in Flex Builder because it increases the speed and accuracy of my development.
Rich, Intelligent IDE's exist for a reason and I don't think it helps the discussion to say the equivalent of:
CD's? why bother? Cassette Tapes work fine.
I'll post new survey stats tomorrow.
One thing's for sure: I absolutely loathe that query syntax (the screenshot). It seems totally backwards from where I'm standing. Even the concept of being able to instantiate a "query" object before executing its sql feels counter-productive and dim. It feels like jogging in place. It's completely reverse from the tag approach, prepare all of your arguments/attributes, hell, put them into a single collection if you're incredible, and then go. Trigger the functionality. Don't author the tag, fiddle with and change it, and then trigger its real purpose with even more typing. That's nutty.
I wish it looked like this instead:
var cfQPs = {
id : { value: arguments.id, type: 'int' },
firstName : { value: arguments.firstName, type: 'varchar' }
};
var sql = "
select *
from table
where id = { id }
and firstName = { firstName }
";
return cfquery( sql: sql, params: cfQPs );
Notice I am NOT instantiating a query object, ever. There is absolutely no reason to. I'm calling a global method that does what it should, parallels cfquery, probably the most valuable tag ColdFusion has.
...it would place CF closer to Flex and AIR, and present it as the best product to use as a back end for these applications.
</cfquote>
Disagree, ColdFusion has ALWAYS been presented (and even acknowledged by competing communities) as the best, most-integrated, go to backend for EVERY Macromedia/Adobe client technology. I don't think richer scripting support will have any bearing on that.
<cfquote source="Davo" >
That could seriously grow the user base for CF, especially if CF9 has tighter Flex/AIR integration (I can only speculate it will).
</cfquote>
People don't switch languages/platforms/insurance providers/video game consoles just to be able to parallel their previous experiences (script syntax). They do it because of some frill, productivity gains, economic benefit, reputation, sex appeal, or improved experience. Call me a prophet, but better script support won't convert ANY people to ColdFusion. If anything, the "not a real language" peddlers will change their tune to "so you've finally caught up to 1998" roasting. If anything is going to get ColdFusion adopted it's 1. Exposure and 2. the redux of significant, measurable development and maintenance reduction as the number one selling point. Why else use ColdFusion? It's faster to write. More similar to other languages, in ColdFusion's case isn't a boon, it's a de-individualizer. The more ColdFusion simulates and bends its knees towards other languages, the less differentiating it appears.
What it DOES do, is allow Adobe to present a solution to development shops, which is tight knit integration of Flex, AIR and CF. The only thing that scripting adds to that proposition is its familiarity to <insert scripting technology> shops when they are presented with code samples. If development shops are adopting Flex/AIR as their development platform, then positioning CF as a logical inclusion can ONLY grow the development base (IMO).
I kind of agree with you on the "de-individualizer" comment, however, I don't thing being a tag based syntax is CF distinguishing feature. It's all of the bells and whistles that come with it - the PDF creation, AJAX features, SOAP, Exchange, .Net, etc etc integration (I don't have to evangelize here, you know what I mean), and how easy it is to do all of that compared to other languages and frameworks.
Cheers,
Davo
Total results: 629
Yes: 391 (62%)
No: 238 (38%)
TGIF: 629 (100%)
<cftable dataProvider="#obj.getData()#">
or even... <cf:table> ? But in same time obj component will be described in external CFScript file as written above.
For me pesonally, implementing logic with CFScript looks faster and cleaner than with CFML. I think CFScript should become more what ActionScript is for Flex.
BTW: Bunch of people I work with came to Coldfusion coding from scripting world and CFScript was their bridge from PHP/Perl/Python to Coldfusion.
As a side note, while I think it's a good idea for Adobe to promote CF as the ideal backend for Flex apps, from some of the comments here, it appears that there are those who feel that CF is ONLY good as a Flex backend -- WTF?
Yes, yes -- I realize that I would still have the choice to not use cfscript, but my concern would be that CFML would develop an identity crisis and further fragmentation is the last thing a community as small as the CF community needs. A previous poster commented how in the future, open source CF projects might start using more and more script in their model code and it gave me flasbacks of my days trying to wade through OS PHP code -- yuck! I also don't relish the prospect of the CFscripters telling those like me in a few years that my code is stuck in 2008.
Anyway -- maybe it's me with the inferiority complex. I totally get that everyone has a right to their opinions and their coding preferences and that it's good that Adobe is listening to the call for more cfcript support. But the bottom line is that -- for me, personally -- it's depressing as hell to see that most CF developers (according to Ray's poll) are pretty much saying that they're unhappy with the syntax they're coding in and it bodes a shift in the language away from what made it such a huge selling point for me.
What I was thinking of (and may not express well with my one-legged English) is that CFML and CFScript should be interchangeable as MXML and ActionScript are in Flex. That will give freedom to developers and silence those telling 'Coldfusion is not serious technology because of its taggish language and lousy OO model, blablabla'.
After getting to know Flex I started to adopt it's approach in Coldfusion - I use CFML tags for describing interface and CFScript for implementing logic. Even for queries - we used to create homebrewn ORM implementation in our team and not using <cfquery> tag anymore. Probably, some will say it's much handier to use <cfquery> and not to wiggle with CreateObject...
>> After getting to know Flex I started to adopt it's approach in Coldfusion - I use CFML tags for describing interface and CFScript for implementing logic.
That is exactly how I feel. The more time I spend writing JS and Java the more want to forgo CF tags when writing logic and functions. Tags are ideal when dealing with XHTML. But when writing functions in a CFC, tags get to be a bit much. I spent a year writing PHP and I really missed the simplicity of using cf tags. Escaping quotes and concatenation gets old very fast. But at the same time writing a paragraph of text in order to pass in variables to a function with a dozen args is overkill too.
As far as the simplicity of tags, and reducing the learning curve, having inspection and autosuggest for external libraries and local vars, a la Bolt, will make it much easier for noobs to get the hang of using CFScript.
[Add Comment] [Subscribe to Comments]