Should Centaur have a CFScript version of every tag?

No, it shouldn't that will just give Adobe twice the work to work on ColdFusion and nobody wants that I prefer more updates on the tag based syntax.

I wouldn't like to see a .cfs file format as that would commit developers to use nothing but scripting in the file - no tags. If they want to use a tag they'd have to change back to .cfm. Sometimes code is easier to read or quicker to write using tags rather than scripting. I don't think a query() function would be as quick n' easy as cfquery for example.

On the plus side if Adobe market CF9 with the ability to use pure scripting (no tags) then it may earn extra respect from people who didn't take a tag based language seriously. It would make it easier for developers who know other scripting languages to try their hand at CF, or adapt if their boss puts them onto a CF project.

Then again, if pure scripting becomes a feature of CF9 it will send out mixed messages and perhaps turn away those who would be attracted to a tag based language. Swings and roundabouts. I guess the question is, does CF need to radically change with the times, has its market and user based changed? I believe it has.

It's already been proved that it's possible. Someone (Sean Corfield I think) wrote a cfscript alternate for every CF tag. It would be nice if Adobe at least gave us a few of them. CFQuery, CFDump, CFMail, and a few others.

I do not think we need every tag in script. There are some things that are still "needed". The last post spoke to that concept. There are other things that would be a great benefit.

There are as @Gary mentioned many who don't take a tag language seriously. Are they wrong, yes IMO. Yet, we can't get them to look at CF for the same reason. Growing the community has potential with at least a near complete script. Of course opinions vary on this.

it's called cflib you guys

http://www.cflib.org/library/CFMLLib

For my part, I would love to have every tag available from cfscript and I think a .cfs file would be really nice.

Of course, I am saying that in a vacuum. It would be really nice to know what other potential feature(s) I would have to give up to get that.

@dfguyy We use CFLib as a stopgap now. Yet, having abort(), throw(), dump() and a few others would be great. IMO we should do our queries in CFCs. (My style note.) If that is true inside CFC just create a function for the query and move on. Yet, if the only thing that held all these tags from going into CF8 as script was CFQuery... then just like we pass in arguments as a structure into tags... make this tag the exception and require passing in a structure of name/value pairs into the query(parameterStructure) request. :)

Yes, I think it would be great to have all of them available but not at the cost of new features. As someone who is copying code from Java a lot lately I think it would make it a lot easier and feels more natural compared to Java or c#. Sure having .cfs would be ok as long as you could still use script normal CF.

Personally I would really like to see more functionality in cfscript to complete the exist functionality. For example being able to throw or rethrow from within a try/catch block. If I can do try/catch, why can't I also do throw or rethrow. Not having these reduces the usability of the try/catch block. Having similar cfscript functionality that complements or enhances the existing scripting options would be the most helpful.

I don't think it is necessary to have a whole new file type like .cfs. I agree with others that the ability to switch between the two is quite nice.

Good discussion guys.

@Ryan: you have a good point about wanting it, but not at the cost of new features. I've heard Ben Forta say a lot that for everything that goes into a release, something else has to come out.

I much prefer CFScript to CFML, and err towards script where possible / appropriate. Then again I mostly write application code, rather than stuff that gets rendered in a browser.

However I think we are where we are with the balance of CFML/CFScript, and it's perhaps not the best usage of people's time porting CFML-only functionality to script, especially as most tags can be very quickly implemented as a UDF using CF8's attributecollection functionality to quickly transplant function arguments to tag attributes. This is different from my position prior to CF8, as it was much more difficult to implement function versions of tags.

I don't see this argument being one of CFML vs CFScript, I see it as "tag-based" vs "function-based".

What I might ask of Adobe is that - with new work - they give some more thought to what's best implemented as a tag, and what's best implemented as a function.

To me, the only things that should be implemented as tags are pieces of functionality which lend themselves best to being approached in a tag-like way. Examples of this are CFQUERY, CFSAVECONTENT, CFXML, etc: these demonstrate situations in which the tags "wrap" other text / tags, which - I think - is much easier to do with tags than function calls. If some functionality does not "fit" that sort of processing, I think it should be implemented as a function. The default should be "implement as a function".

Obviously any new control statements (for example the FINALLY construct, or CONTINUE keyword) should be implemented as both tags and script. Control statements and other syntactical (not functional) constructs are the real area that there's a CFML vs CFScript position to have.

I would like the position of CFML (or "the ColdFusion Language", as it's not all mark-up... not even the majority of it) to shift from "tag-based" to "tag-enabled".

I think the defensive position that CFML is easier for people porting from HTML-only is a specious one. No-one's going to get anywhere if they use only tags (and no function calls) on their website, so - like it or not - they're going to have get up to speed with function-calling, SQL, JavaScript and what have you pretty darn quickly.

I also would be surprised how many people are still coming from HTML-only and expect to use CFML in a commercial way. I wouldn't hire a "developer" who had only HTML experience. Who else here would? On the other hand there's the "hobbyist" out there too.. however in my experience, hobbyist developers are usually more savvy than commercial-only developers (people who write code 9-5, M-F and don't have any interest in doing it other than that). But I am also sure Adobe know more about their market than I do!

-- Adam

FFT... we are out here in the community assuming it would take a "bunch of time" to port the technology over to script. Let's consider a couple of things. At CFUnited Forta said something about they had looked at this and the only tag that appeared to be a real issue 'as I remember it' was CFQuery. Hmmm... and even without that mention the core features under the hood here are Java not CFTags. Therefore under the hood the porting isn't like writing new features. That is an old worn out excuse if we take it as if they were creating something new like the Exchange integration of the last beta. I believe it would take time... and it may not be worth a full port. Yet, a partial port of some of the key things is certainly over due. (dump, abort, location, throw, etc.) (And it would be nice if they created a throw option that triggered on the browser side vs server side to make login actually work right! lol

Hi John It would still take some time, and each element of the refactored functionality would need to be put through the testing wringer: unit tests, usage tests, etc.

En masse, that's quite a chunk of work; it's not just a matter of shrugging off the outer tag-based interface to the underlying functionality and adding a CFScript interface to it (and that's it), like you seem to be suggesting.

Also some tags - CFCHART for example in which outer tags need to interact with inner tags - will probably require a bit more work that that.

It's not trivial. It's not immense, but it's not trivial.

-- Adam