For a while now, myself (and many others) in the ColdFusion community have been urging, begging, hell, pleading with developers to stop using UI tags in ColdFusion. Things like cfgrid, cfpod, etc, are easy to use, but in general lead to far more trouble than they are worth. I said this back in October of last year:
CFUI controls are the path to the dark side. CFGRID leads to CFLAYOUT. CFLAYOUT leads to CFPOD. CFPOD leads to suffering.
But as the title says, I'm not going to bother anymore. Nope. Instead, myself, Adam Cameron (and hopefully others) are going to tell you what to use instead.
We've launched a new project called ColdFusion UI the Right Way. Yes, that is a pretty opinionated title. But Adam and I are pretty opinionated guys so this is to be expected. The idea is simple. For each of the UI tags we will discuss an alternative. We won't cover how to replace every single aspect of CFGRID (as an example), but instead focus on the high points and give you an idea of how you can go further. Also, each section will include demos you can run locally (with no set up) and a list of other alternatives. We won't be focused on one UI library. Rather, Adam and I (and anyone who contributes) will use whatever they are most familiar with.
Again - the intent is to stop saying "Don't do X" but instead say "Do Y instead" - which I think we can all agree is more helpful.
Archived Comments
are you thinking they could be drop in replacements <c:input vs cfinput
or just listing alternatives/frameworks that people could use
I don't think it is fair to say "drop in replacement" - the idea is to focus on the main goal of the tag. Let's take cfgrid. It's main purpose is to render data in a tabular format, with options for AJAX binding and pagination. An article on this could use jqGrid. The article would NOT cover every single argument of cfgrid and show you how to do it - but rather focus on those main goals. The idea being that if you want to do something weird with it, you have more power having your own solution as opposed to cfgrid which may lock you in. (Or, when you upgrade, your code may stop working.)
Does this make sense?
Thank you for this Ray...as always, good knowledge.
Would you please make sure cfclient doesn't end with the same fate??
and if you can blog about how to use cfwebsocket without its generated crap that'd be great. :)
This could be good. As to something that I would like to see specifically is how to replace cfgrid effectively. I have always struggled with this. A couple of feature that we use are the toolbar with custom buttons and the other aspect is when you are dynamically creating grids, you might know what the columns are ahead of time, but you might have 5 of these grids on a page or more or less, so you don't know the names of the grids. I've found using the query attribute in cfgrid handy for this.
I haven't had time to work with jqgrid much, but so far I've struggled with jqgrid. I found cfgrid much easier to use with the limited time I have.
Most of the other stuff I've been able to replace with jqueryui.
Looking forward to some good stuff on the site!
Ditto. I just did a quick project for a client, and the initial search form and result list is based on jQuery DataTables. It retrieves its JSON data from a CFC component via AJAX, but that’s all back end code.
The entry form is based on my latest DataFormJS code generator, which is itself tightly integrated with the client-side jQuery Validation Plugin.
Backend data services are provided by the 2nd-generation DataObjects ORM, layered over a SQL Server 2005 database system. Other than the aforementioned AJAX code, there are no hand-written queries whatsoever.
Report generation is handled by ColdFusion, though embedded chart generation is handled by Highcharts JS due to various printing and integration issues with CFChart.
So. No CFForms. No CFCharts. No CFGrids. One custom CFQuery.
I think Ben Forta said it best:
"In my opinion there is no longer a compelling reason to use any ColdFusion features that generate client-side code for you. Be it UI libraries, form validation, data grids, menus, embedding maps, and more, there are now so many alternatives that are clean and lightweight and easy to use that it is more productive to just use those instead."
Count me in.
http://www.hmlong.com/2014/...
Love to throw in some assist on this. Can give some bits for Bootstrap, JQUI, jqGrid, DataTables, and even some ExtJs (if I brush up some).
@HenryHo: I can't comment on cfclient while it is still in beta. I actually *like* cfwebsocket - especially how it handles server side events.
@Cutter: What I need to figure out ASAP is a way for folks to "claim" a tag. i don't mean like a promise per se, but it makes sense to know that person X is working on tag Y that way we don't duplicate effort.
For now I'd say - if there is something in particular you want to start writing, let us know first just so we can organize.
Fantastic Idea!
@Ray: "What I need to figure out ASAP is a way for folks to "claim" a tag." I say you don't. In the repo just create folders after each tag, then individual devs can submit their solutions into the folders.
If I'm in love with cftextarea, and someone says "Use tinyMCE", and I turn out to hate tinyMCE, I'll go back to my old ways, but if I see a list of options, I'm bound to find one I do like.
Maybe under each folder named after a tag, you have the files named after the JS framework: Native, jQeryUI, Angular, EXT.. Point is due to varying tastes, there will never be any good list of one to one replacements, so whatever format you do, leave room for multiple options.
Also this might be a good place to start:
http://stackoverflow.com/a/...
@Tim: My gut says - and I'm not speaking for Adam here - that I think it would be bad to have multiple solutions. I'm thinking of this as a book - and to me - it makes sense to be focused and direct - to not overwhelm the reader. Each section will have a list of alternatives, but I think the main text should be focused on one.
I would be glad to help with this also. I have even written a tag to replace <cfajaxproxy /> using jQuery. It did introspection of CFCs and wrote a JS file to work as a static proxy object. The object was only updated when the CFC was updated.
The only fault we could have here is over assuming the CFTags are doing it right. Sounds like this group is not going to be prone to that error. :) Yet, some will just be looking for one on replacements of CF Tags.
Note: One of my current side projects is looking at creating elemental directives that have back end CFML tags driving directive element restricted tags in AngularJS.
When can I use my quote "cfDo or cfdo not, there is no cftry"?
Some of us have very large code bases to work with. It would be useful to have a tool that could rip through a website and give listing of all the things that it finds that are not "best practices"
I've found on recent small projects that using something like angularJS on the client side and CF on the back end to manage the angularJS model has worked well. As far as UI/UX is concerned, add in stuff like Angular-xeditable and it sometimes feels like it's too good to be true. (so it probably is)
No idea how this scales to bigger, more complex projects but it sure feels cute
@James: The issue with that is that a lot of times, best practices is hard to quantify. I know someone did begin work on a linter for CF. Not sure of the status though.
Someone on IRC recommended Isaac Schlueter's video at http://www.youtube.com/watc... (Building compassionate Communities in Tech).
Isaac heartily recommends reading "Nonviolent Communication: A Language of Life: Life-Changing Tools for Healthy Relationships".
The four components of NVC are:
1. observations
2. feelings
3. needs
4. requests
I don't quite understand it yet, but it goes something like this:
1. observations:
I see that you want to use cfform because it's less coding for you and it defaults to method="post".
2. feelings
It hurts the Internet when you do that.
3. needs
I need you to quit being such a total noob.
4. requests
I'm gonna have to ask you to come in tomorrroooowww. We sort of have to play "catch up". That would be greeeeeat. mmmmKay?
I so totally need help converting all of my cfform, cfgrid, cfdiv, applications to something like bootstrap, datatables, etc. this site could revolutionize my apps and make me a hero!
your introduction says no datasource is required but if you are only using the datasources that come with ColdFusion by default (cfartgallery, cfbookclub) it would be ok by me, especially for dynamic UI elements like data grids.
@Michael White: We are going to use fake queries when we need to show a query. Ie, queryNew(). My first example (I'm doing cftooltip) will hopefully we ready Monday.
Just curious, but are you proposing a single set of solutions that can all be used together, in a single site?
For example, DataTable, jqGrid, and jQuery Validation (forms) are all jQuery-based, which is fine just as long as the site didn't choose Prototype as its JavaScript base. (Or forgo jQuery/Prototype-style altogether.) And none of them might be what you'd choose if you'd been wanting more Angular or Backbone.js integration in your site.
I've been playing with a slick form generator implementation based on Semantic UI, but what if your site uses Twitter Bootstrap?
I guess what I'm saying is that there might be different "sets" of solutions, as each one depends upon your particular development stack.
No, this is not meant to a "Always use jQuery UI for X" type solution. The idea is to guide you to how you could replace the UI controls. In fact, we really want to ensure multiple different types of solutions are shown so folks get exposed to different things (Ext, jQuery UI, native HTML5, etc).
We want users to learn - not just copy and paste the code.
That's kind of how I feel about it, which in turn makes me wonder if you don't need different examples for each replacement. It wouldn't be too hard, for example, to do a section on tabs, and show a brief sample of how you'd code it for jQuery UI, or Bootstrap, or Semantic UI.
Forms are more complex, but again, seeing jQuery Validation stacked up against Semantic UI could be beneficial too.
Many solutions may actually be too complex to cover completely (there's an entire site for all of the jQuery Validation options), so you might just consider compiling a set of "resource" articles. "10 Alternatives To CFForm." "8 Alternatives To CFLayout."
Each alternative could be a screenshot, a description, a bit of sample code, and then a link to the resource for more information.
Well, each chapter *will* have a list of alternatives, but I do not want to make this overly complex. The main portion of the chapter focuses on ONE option. That way it is more focused, more direct, and easier to read.
I really don't get where this is coming from.
When inheriting piles of terrifying legacy code, never have I said "Whoa this is horrific code to maintain, they used CFForm!" There are multitudes of other sins committed daily that deserve far more attention than use of tags like CFForm, CFGrid, etc.
Besides, in some situations, I find some of the tags to be quite useful, and very fast to implement. Okay, maybe not CFPod. I don't feel that I need 17 JS libraries to create a form with 4 or 5 fields that submits to the database. If we are talking about an Enterprise application with piles and piles of larger to massive forms, maybe CFForm doesn't make as much sense.
Don't get me wrong, I am not advocating widespread use of CF UI tags. I do advocate limited use of them though, and believe that there are much more egregious sins to address, ranging from 'For the love of God, please stop putting queries in cfm files" up to "Lets have that boundary layer talk again" to "Yes, indexes are good things to have on that table that has 75 million records and runs really slow". These are the kinds of things that just kill me when inheriting legacy applications, even ones newly written, never the use of CF UI tags.
Maybe I just get exposed to a different set of problems than most.
"I really don't get where this is coming from."
Mark, I probably just assumed most of my readers knew as it has been discussed. A lot. To be fair, not everyone attends conferences nor pays attention to all the blogs (who can?), so I can understand if you missed it.
In a nutshell, these tags offer 'quick fixes' to solutions, but in many cases, people find they need to do something not supported by the tag. Then you are - essentially - stuck since you a) didn't learn how to really do the thing (grid, pod, whatever) or b) you figure out how to make it work and then get screwed when the next version of CF updates the engine being used by that particular UI feature.
It is my opinion, and I am not alone in this, that it is *much* safer to simply let CF handle the back end stuff, where it kicks ass, and do the front end stuff yourself where you have direct control over all the pieces.
Finally, if front end work makes you nervous, scared, or whatever, then this is an excellent opportunity to get over it, learn some new skills, and become more marketable in general.
Are there more important things? Surely! Does that mean we can't work on *this* problem? I don't think so. As I said, many of us in the community just say "Don't do it", and this aims to fix that by saying "Do this instead."
For folks looking for an example, I've checked in one for cftooltip.
This is a great idea ray. At my last job I had extensively used cfgrid and cfwindow with all kinds of hacks/workarounds. Then of course after the cf server was upgraded, a lot of the features broke. The only defense for using them previously was that the other options available at the time were much more involved and time was essential. One chapter I would love to see is on cfchart. Its a powerful, easy feature but once you need advanced/specialized charts it becomes a nightmare to control. Would love to hear what other options are out there (that don't cost a fortune and look as nice).
Jason, check the issues on the git repo. I used an issue for a TOC and cfchart is definitely covered.
Thanks for the response Ray. One point of note:
"...they need to do something not supported by the tag"
To me, that is the problem. When faced with needs not supplied by the tag, then don't use the tag. I can dig finding better solutions, because better is, well, better!
I guess what is kind of getting under my skin really is what I see as a larger issue that has become prevalent enough that I stopped reading most CF blogs a while back. Guy tries something unsupported, off the ranch, or just generally unwise. CF reacts in a way they didn't expect. Bash CF blog entry ensues. Note that I have not seen anything like that here on your blog, but just out there in the Blogosphere.
It just sounds like the flavor of the month to bash has become the CF UI tags. Yes they can be abused and very very often are, and yes there are usually better solutions. But there are also times when using them makes sense. Perhaps blanket statements in this case are not optimal.
Mark, fair enough. To me, I see a broader problem of CFers not embracing front end stuff as much as they should. So even more than "CFUI is Evil", I'd like to see more CFers feeling more comfortable with the front end.
Ray, I am definitely guilty on that front! Things like SQL Server and index tuning, architecture, and other back end stuff get me all excited. View layer work makes me want to cry, but thats probably because I am bad at it.
UI tags are cool... I don't especially rely on them because they kinda' 'date' my implementation to a specified @release ... However, I think it's safe to say that 'tag based' templating like cfmodule etc is smart. It makes code .... err modular ...
I've gone over to the dark side over the last few years ... working mostly in java and spring... and 'ui' tags are in full swing still ... Spring Webflow, JSF, Primefaces, GWT all use 'ui' tags and those frameworks are heavily relied on ... Moreover, CF is pretty cool in leveraging the ability to make custom tags for UI stuff .... <cf:view> <cf:model_attrib>
That my 2 ....
Right. The latest hotness is Angular. I don't know anything about it,. but I sure am hearing a lot of buzz.
I've been thinking about your encouragement to post into ColdFusion UI, the right way. and one of the reasons I'm hesitating is because I have a unique point of view on how to write everything in both ColdFusion and JavaScript. I'm sure that if I were to post a "chapter" in ColdFusion UI the right way, both you and Adam would ask "Why do you do it that way?" and would proceed to correct it.
I touched on this as a comment to a different blog post of yours, so the irony is not lost.
I guess what I'm saying is that I think it's great that you and Adam are publishing "The right way" according to your point of view, and I'm watching that github project closely.
For me to show an example, I would want to have control over the editing.
So: I guess, maybe, I need to change my attitude?
In terms of this project, I am not interested in insisting on a particular style. I *want* to see different styles as it gives people different approaches. I *am* interested in ensuring things keep simple, practical, and that it is readable. I'm also want to ensure we follow a similar 'skeleton' to the chapters (ie, having the list of alternatives at the bottom for example).
"For me to show an example, I would want to have control over the editing.
So: I guess, maybe, I need to change my attitude?"
Well, it is a collaborative project. People are going to correct English, typos, etc. I don't think you will see people totally change how something is done. Not w/o debate first.
Any example of cffileupload multiple alternative. Coldfusion's "cffileupload multiple" is great and simple. Unfortunately Railo doesn't have that tag either.
It looks like we don't have that one yet. Sorry. Keep watching the project.
FYI: https://twitter.com/henryle...
"As decided we won't invest any time in Ajax UI components"
- Uday Ogra
11:20:23 PM GMT+00:00 Jun 29, 2014
https://bugbase.adobe.com/i...
I refuse to believe something so big would be announced like that. But I'll check. ;)
Checked. Not true - misunderstanding.
I used cfgrid once many years ago. I can confirm that it has been nothing but suffering since then. Hopefully one day I'll have time to rewrite that module, but it truly has caused us (and our users) nothing but problems.