Thanks to a coupla people fwding my Twitter status updates asking for participation, and I guess repeated nagging from myself; on Friday last week I finally hit my target of 50 responses. I've closed that survey now.
The results were fairly predictable, I guess: no-one's interested in UI-ish things (form, layout & UI widgets) being availed in CFScript, and a bit of a mix in between. Basically people thought "internal" type stuff, or integration with some external systems warranted inclusion in CFScript, but were a bit "meh" about it other than that.
I understand the extremes, but I don't understand the general "meh"-ness of the topic. I s'pose I come from a perspective of having never really liked tags unless I'm mishmashing them with HTML, and the longer I code, the less time I spend doing that, so the stronger and more-full-featured CFScript is the better, IMO. That said, I know a coupla people I work quite closely with are completely content to write all their logic in tags, so opinions vary. I find tag-based code rather hard to read, comparatively, I have to say.
Anyway, the table is below. I've not posted the individual votes-by-category (eg: "should not be implemented" through to "must be implemented") as they're a bit meaningless taken in isolation, I've just give the weighted total. My weightings were:
| Vote | Weight |
|---|---|
| Should not be implemented | 0.0 |
| [between] | 0.5 |
| Neutral | 1.0 |
| [between] | 1.5 |
| Needs to be implemented | 2.0 |
| Don't know | 1.0 |
This just gives a score which is meaningless in itself, but can be used to compare to other tags' scores. In the table I've colour-coded each grouping (as per the second version of the survey which was categorised rather than one long list) separately via background colour, and the tags are listed by category, and the categories are in the order of "most interest in seeing this lot in CFScript", down to "don't generally care" (based on the average score for the category). The text colour reflects which... err... quintile (? in groups of 20%, anyhow) the score sits in, as follows:
| Vote | Weight |
|---|---|
| 0-19% | red |
| 20-39% | orange |
| 40-59% | yellow |
| 60-79% | blue |
| 80-100% | black |
This makes for a bit of an assault on the eyes in some places, sorry. I think I have even trumped Railo's <cfdump> colour-scheme in the "far too garish to have to look at" stakes. Anyway, it's there to be glanced at, not pored over, so hopefully I won't do your eyes any permanent damage as you look at this.
OK, here's the table:
| Tag | Category | Weighted score |
|---|---|---|
| <cflogin> | Security | 81.5 |
| <cfloginuser> | Security | 81.5 |
| <cflogout> | Security | 81.5 |
| <cfntauthenticate> | Security | 78 |
| <cfcollection> | External Systems | 79.5 |
| <cfexchangecalendar> | External Systems | 69 |
| <cfexchangeconnection> | External Systems | 70 |
| <cfexchangecontact> | External Systems | 70 |
| <cfexchangefilter> | External Systems | 70 |
| <cfexchangemail> | External Systems | 70 |
| <cfexchangetask> | External Systems | 70 |
| <cfindex> | External Systems | 87.5 |
| <cfinsert> | External Systems | 55.5 |
| <cfobjectcache> | External Systems | 76.5 |
| <cfregistry> | External Systems | 75.5 |
| <cfschedule> | External Systems | 90.5 |
| <cfsearch> | External Systems | 88 |
| <cfsharepoint> | External Systems | 67 |
| <cfupdate> | External Systems | 57.5 |
| <cfdocument> | Doc/File | 82 |
| <cfdocumentitem> | Doc/File | 81.5 |
| <cfdocumentsection> | Doc/File | 80.5 |
| <cfpresentation> | Doc/File | 51 |
| <cfpresentationslide> | Doc/File | 50.5 |
| <cfpresenter> | Doc/File | 49 |
| <cfreport> | Doc/File | 58.5 |
| <cfreportparam> | Doc/File | 58.5 |
| <cfzip> | Doc/File | 94 |
| <cfzipparam> | Doc/File | 94 |
| <cfassociate> | Misc | 56 |
| <cfcache> | Misc | 66 |
| <cfcontent> | Misc | 76.5 |
| <cfexecute> | Misc | 84 |
| <cfflush> | Misc | 71 |
| <cfheader> | Misc | 75 |
| <cfhtmlhead> | Misc | 67 |
| <cfmodule> | Misc | 62 |
| <cfprint> | Misc | 47 |
| <cfsetting> | Misc | 77 |
| <cfsilent> | Misc | 44.5 |
| <cftimer> | Misc | 64 |
| <cfwddx> | Misc | 60.5 |
| <cfajaximport> | Form | 33 |
| <cfajaxproxy> | Form | 33.5 |
| <cfapplet> | Form | 25 |
| <cfcalendar> | Form | 24 |
| <cffileupload> | Form | 55 |
| <cfform> | Form | 21 |
| <cfformgroup> | Form | 20.5 |
| <cfformitem> | Form | 20.5 |
| <cfgrid> | Form | 23.5 |
| <cfgridcolumn> | Form | 23.5 |
| <cfgridrow> | Form | 23.5 |
| <cfgridupdate> | Form | 24 |
| <cfinput> | Form | 21 |
| <cfselect> | Form | 23.5 |
| <cfslider> | Form | 23.5 |
| <cfsprydataset> | Form | 26.5 |
| <cftextarea> | Form | 22.5 |
| <cftextinput> | Form | 23.5 |
| <cftree> | Form | 23 |
| <cftreeitem> | Form | 23 |
| <cfchart> | UI | 30 |
| <cfchartdata> | UI | 30.5 |
| <cfchartseries> | UI | 30.5 |
| <cfcol> | UI | 20.5 |
| <cfgraph> | UI | 25 |
| <cfgraphdata> | UI | 23 |
| <cfmap> | UI | 24 |
| <cfmapitem> | UI | 24 |
| <cfmediaplayer> | UI | 23 |
| <cfmenu> | UI | 22 |
| <cfmenuitem> | UI | 22 |
| <cftable> | UI | 20.5 |
| <cfdiv> | Layout | 20.5 |
| <cflayout> | Layout | 21.5 |
| <cflayoutarea> | Layout | 21.5 |
| <cfpod> | Layout | 22 |
| <cftooltip> | Layout | 21 |
| <cfwindow> | Layout | 22 |
Oh, a word on some of the scoring. Where people had scored at category level, eg: "All form management tags (answer this one OR all the individual ones below)", I added their score to each item in the subcategory. Where people voted for the category and a tag within the category, I kept the score against the specific tag. This seemed most fair. Basically I used the category vote as a "default", which was overriden by specific results.
Two people filled in both the "default" and each individual tag. Aw bless.
One person seemed to think "<cfassociate>" was the "whole category" item for the last "misc" group, and just checked that one, leaving the rest blank. [eyeroll]. Is it that hard to read something? Apparently.
So my opinion of this is that Adobe should put effort into implementing the tags that fall into the top 60% of the results: the yellow, orange and red ones. Some people might baulk at the notion of doing <cfchart> - which is "clearly" a UI widget - but bear in mind a <cfchart> tag doesn't solely output a chart on the screen, it can generate a binary too. So if it makes sense to do the image functionality as functions, it makes the same sense for <cfchart>. And I think it does make sense.
What things am I surprised about?
- <cfregistry> made it into the 60-80% grouping. How come all votes weren't "who cares?" (I know didn't give that option, but people obviously voted, so did kinda care).
- <cfwddx>. This was in the same grouping (60-80%). I can't see why this isn't in the top grouping: it's a sitter to be implemented as function: it takes an a vaule and processes it into another value. I'd ask why the hell it was ever a tag, rather than a function from the outset. Well: a pair of functions. I guess people don't care about WDDX so much these days, with JSON's ubiquity.
I got a few comments (my feedback is inline):
God that was hard to complete. You should have grouped tags from the same family into one. e.g. all the cfform tags as 1 option.You lead a very charmed existence, my friend, if you think making 80 mouseclicks is arduous. I am envious of you.
This is in the pipeline. It's going slowly (not Coldbox's fault, my fault)
You should do another post on your Coldbox experience, I'd love to see your findings. Maybe you'll even convince me that its better than CFWheels ;)
Actually I am, in the above-mentioned Coldbox project. Only because I'm being lazy, and my requirements are minimal and exactly matched by the functionality <cfform> offers. So: kinda the use case for <cfform>, really.
Most of these tags I seldom have any use for. I like your analogy tags for views.
Are people really still using cfforms?
Yep. That's what I'm trying to push for here by banging-on about CFScript completion, and raising community awareness (again, with the banging-on about it).
CFScript changes really needs to focus on making the language more consistent. Standardize the function naming scheme; take cues from other web languages for function names. The core features of ColdFusion should be available in either CFScript OR CFML. I shouldn't have to drop in and out of <cfscript> blocks to write my pages.
Yeah, I agree with the Query.cfc sentiment, although my disagreement is mostly that they've done it as a CFC - which is just a lazy cop-out - rather than do it properly in Java like the rest of CFML (except the other similar CFCs). These CFCs are the nadir of the Adobe ColdFusion Team's development efforts.
I don't use most of the UI or MSFT tags... and that's what many of these are. In addition to the obvious piss poor implementations of cfquery, I find that savecontent is MUCH harder to implement now - especially where you have content with nested single and double quotes. I know there must be an obvious reason why Adobe cannot do this, but as an interim solution, it sure would have been nice if they could have implemented something like the reverse of cfscript, i.e. in the middle of a script cfc we could stick in a simple cfquery tag and surround it with "tag" or some such. As is, when script won't do, I break it out into a separate file and include it. Not pretty, but doable.
I was surprised too! I've hardly used any of them.
Seeing this list makes you realize just how many dumb UI-related tags CFML has!
You can't count, mate. But, yeah, for the ones that what you say does apply to, I mostly agree.
This makes me realize how many of the tags I never use. I've usually found external libraries (Java:POI, Javascript:jQuery) have been more useful than the CF equivalents.
98% of these tags are display only tags, and having them written in script is really not an option I would like to see ColdFusion ever adopt.
you can do cffileupload in scriptSorry, yes you can. The list I based this on was concocted during the ColdFusion 9 pre-release, and that came in in CF 9.0.1, and I didn't update the list, sorry.
Ours too.
In general, I don't think it is as important for CF javascript helpers or cfform types of tags, but other tags are important.
I really don't think that Adobe should spend their time on any of the UI/Form/Layout tags, since these make more sense to use as tags anyway, and most people agree that the tags should be deprecated.
our DAO objects are all tag based. A cfquery tag just looks nicer and is easier to read the SQL statement than a query object. our cfml templates are all tag based as well. It looks better with the html.
But... it could be fixed / improved, yes? That's the driver behind this. I think CFScript is actually pretty good these days, and I can write almost all my code with it. I was bitten on the bum the other day when i had a Script-only CFC that I realised I had to put a <cflogin> tag into (don't ask). That sucked a bit.
I'm kindof "bleh" on all this, because the connection between tag-based and script-based versions of the language is a complete disaster.
Yeah, I think Railo does this? I was cool on the idea initially, but - as I have been writing a few custom tags recently - I have really warmed to the idea.
I'd love to see as much cfscript coverage as possible, as well as more ECMAscript language features implemented. However, I'd also like to see custom-tags implemented as CFCs and expansion of the UI tags. In fact, I'd like to see some functions implemented as tags (officially).
Yes. I'm tying to encourage Adobe to do something about this. That's the whole reason for this line of enquiry.
To be honest, I am not a fan for cfscript because the current implementation is not complete. In addition, I believed cfscript was intended to attract other developers, such as PHP, ASP, etc. to feel "home" when they migrate to ColdFusion.
That's about it. Any further thoughts? I'm gonna push this Rakshith's way, to see what he thinks.
Righto.
--
Adam
