This is gonna be quick as I'm a) hungover (yeah... 10pm and I'm still hungover from y/day!); b) had a few medicinal beers to try to deal with (a); c) absolutely nackered, and want to just vegetate and watch a DVD.
I want to actively participate in the demise of <cfform>, <cflayout>, <cfajax> and the like as "a thing" that CFML developers might accidentally use.
First some background. Back in the days of CF5 (maybe through until CFMX7?), Javascript was a pain in the arse to use, as no-one had yet really attempted to create a uniform, cross-platform solution for doing anything useful with JS. JS was just a pain in the arse. We were using image tags and cookies to perform inline requests (this was before "AJAX" had a name), or maybe worked out how to get both IE and Netscape to request XML in the background (and return mark-up in the payload in lieu of XML). But it was unreliable and everyone (incl. the browser vendors) seemed to hate it.
Aside:
My first CFML mentor was a chap called Jim Davis, who ran a blog depressedpress.com, and posted a lot on alt.comp.lang.coldfusion. His article on GIF Pipes still exists. It's brilliant!Anyway, back then <cfform> was a godsend. it did cross-platform JS validation! It didn't do much other than that back then... no Flash... no XML forms (I still don't know WTF those are, but fortunately I've also never ever ever needed to know either)... no data binding... but it did simple JS validation OK, which was better than I could do. So: fair enough. There was a place, and a time, where having CF help out on the UI made sense.
A decade later... no. Just NO. The JavaScript / web UI world has grown up and surpassed anything ColdFusion can hope to do in a wizard. ColdFusion uses out-of-date libraries, and the JS it writes is... well... just not very good. The bods on the ColdFusion team might be fine Java developers, but I'm afraid they are absolutely not web developers (nor CF developers), and it really shows in the client-side stuff they turn out. So even if there wasn't the consideration of the JS community having moved on and past ColdFusion's UI wizards, the CF solutions simply aren't very well realised.
One of the best thing Adobe could do for CFML's credibility is to dump all the stuff that attempts to do client-side stuff (AND STOP DEVELOPING NEW CLIENT SIDE STUFF!!! [cough] <cfclient> [cough]). But they're not likely to do that as they are allergic to tidying up their cruft. There is a reasonable case for backwards-compat concerns if they dropped <cfform> etc lock-stock, so they could at least move it out of the core language, and make it a separate download. This would be a start in discouraging people from writing new code using this nonsense. And that would be a community service.
And here - after 500 words - is where we start getting closer to the point of this article.
Recently some people in the community commenced actively railing against <CFFORMetc>. Scott Stroz and Dave Ferguson have both been actively dissuading people from using this stuff when questions arise on Stack Overflow and various places. As well as echoing the sentiment on the CFHour podcast. I have joined in if I can.
I'd like to ask the rest of the community to join us in a concerted effort to help people move away from using <cfform> / <cfpod> / <cfajax> / <cflayout> etc.
Another thing I was thinking of was to create a resource along the lines of "Learn CF in a Week", except kinda "Unlearn <cfform> in a week" or similar. The idea being that people could collaborate to volunteer code that effects the same functionality as ColdFusion's UI tags, except using decent solutions using good mark-up, CSS and JS. If this resource could target the same SEO keywords as <CFFORMetc>, if people looked for help with these tags, they'd possibly find a better solution. At the very least it would be a resource for using on Stack Overflow and the Adobe forums to help wean people off: a repository of ready-made code examples for "how to solve your problem without using <cfform>".
I was going to try to effect this by simply writing a bunch of articles on the topic on this blog, but the problem is that I'd have to get up to speed with <cfform> myself first, before explaining how not to use it. And then learn how <cflayout> works to discourage its use. Etc. And the advice I give on the topic applies to myself too: being able to wield <cfform> is not a useful skill to have, so I don't want to waste my time learning it. But as a community we must have heaps of code examples out there covering this ground, mustn't we? Well some. Maybe.
Another challenge is I don't know how best to implement such a resource. Just a github repo? Not very Google-friendly. A blog? Maybe. Any other ideas? Or does this just sound like a daft idea? Any volunteers to help?
Lemme know your thoughts.
--
Adam
