Caleb asks:
First of all I'm only 6 months into ColdFusion so this may come off as a silly question. I see elements in the documentation like <cfform>, <cfdiv>, <cftable>, etc. Many already have an HTML equivalent. I was wondering if I should be using those in place of my typical <form>, <div>, or <table> tags and if so, what is the benefit?
This is an excellent question. I haven't been new to ColdFusion for 10 years, but I can definitely see how someone new to the language would be wondering about exactly this issue. While other language elements like cfif, cfhttp, etc, have no relation to the actual rendered page, the tags you mentioned all do client-side items that can be done in "normal" HTML.
The documentation does describe each of these tags. I'd encourage you to check them out in the reference to get the basic syntax rules. For some of these items you should also check the Developer's Guide for more in depth coverage. There is an entire section on cfform (chapter 30, Building Dynamic Forms with cfform Tags) and cfdiv is discussed in depth as well (chapter 34, Using Ajax UI Components and Features).
In all cases, each of these tags do things that you could do without ColdFusion. As an example, cfform makes it easier to do serverside and clientside validation. As I covered in my blog last week though you can do this yourself with jQuery. As another example, cfdiv makes it easy to create a region that can be loaded with content via Ajax. Again, jQuery (and other Ajax libraries) can do this as well. So why bother?
ColdFusion has always been about making web development easy. For a long time now this has been more than just serverside stuff. Both cftable and cfform are pretty old. ColdFusion 8 added cfdiv and many other Ajax features. If you don't know JavaScript, these tools can be a life safer. The benefit here then is something ColdFusion shines at - RAD.
When ColdFusion 8 came out there was some debate about whether Adobe had wasted time building so much client-side Ajax functionality. My opinion is that this was the right move on Adobe's part. I think a lot of people forget that the those of who actually read blogs are probably twice as advanced as most users.
So to (finally) answer you Caleb - should you use it? Sure. If you find that they aid your development then why not? If you feel more comfortable writing your own JavaScript (just to pick on cfform/cfdiv specifically) then use that instead. Ditto for any other feature.
Archived Comments
I agree with what Ray says.
The clientside cf tags and features allow for RAD development. Generally I will start with those tags and if the look or complexity needs to go further than what CF provides will look to jQuery or Spry. The back end code at most then just needs to be tweaked.
I also find the CF clientside features to be very useful for admin or internal facing sites.
I have to admit, for a lot of admin or internal facing apps, I find my self using <cfgrid format="html" /> quite a bit.
Its quick, its easy and I like the UI.
In Ray's latest twit he says this is "exactly why I'm not allowed to do design work".
This brings up a good point. I've heard about companies who let the developers produce the raw content and allow the designers to mark it up and display it as they see fit.
Do you think this would be a hit against those tags as it would require either the developers to take on some of the design work or the designers to learn CF.
Also does CSS treat a <cftable> the same as it would a <table>? Maybe I should just test it instead of adding it in a comment. :-)
There is a bug in the <cftable> <cfcol> when you pass a blank value to the <cfcol> it will not close the <td> tag. So he should be avoiding that tag.
Wow...peole actually use <cftable> enough to know that a bug exists?
I am stupified ;)
Caleb - In the tags you mentioned, I think only cftable really falls into the category of 'complete lock down' in terms of UI. Stuff like cfgrid can be styled to some extent. I think it is a trade off. You can build an ajax-based grid w/ cfgrid in 4 minutes. With 0 JS experience. That is incredible. But you may not be able to style it as much as jqGrid (and I just throw that plugin out since it is fresh on my mind).
I kinda discussed this recently in my jQuery versus CFAjax post (http://www.coldfusionjedi.c... so this post may be a bit of a dupe (sorry!), but kinda the same rules apply.
You guys are awesome and thanks Ray for the prompt response to my e-mail. I honestly didn't expect a reply for at least 24 hours.
Hey, Raul... have you raised that bug... errr... "somewhere" (don't answer that)? Now's a good time to try to get these things fixed, after all...
--
Adam
I am with Scott on this one. I am amazed someone actually used cftable to the point to find a bug!
@Adam - Don't forget that anyone can report bugs: http://www.adobe.com/go/wish
Yo are right Adam, raised on both places
CFTable rocks for generating fixed width content. We use it fairly often to feed data to back end processes. Just strip out the pre tags & you're good to go. The HTML version's fairly handy for quick output of data, but not much faster to code than just doing your own table and looping the rows (and most of the time I wanted something that fast I'd just cfdump it anyway)
CFGrid is a really useful tool. I use it for a fair number of things, but the most interesting one is a data entry/cleansing tool. Couple of dozen columns, anywhere up to 1000 or so rows... before we built this thing in house we had a vendor product that tried to do the whole thing using HTML... one big table full of input type=text fields. Took a couple of minutes just to render for some clients, and then IIRC you could only update one row at a time.
Now if only I could get the flash version of it to let me switch the form action based on which button I push....
@JC - No one should be using the Flash versions. Use Flex 3 man, it's free now!
Ray,
I appreciate all of your work in the CF community. One of my thoughts with the front-end tags (cfdiv, cftable, cfform) is that the markup they create is usually not optimal. First, the server needs to process more markup (minimal overhead) and then the client needs to process additional js (again, pretty minimal). But a developer could, with jQuery write the same (or better) functionality that ColdFusion creates in about 70% less code. And if they are using the Google JS API to include jQuery, then there is no overhead in using jQuery.
I have no problems at all using those front-end tags, it is just important that we understand what they actually do. Use them and then look at the html markup that is generated to see what CF is doing for you.
I agree it is important to recognize the performance impact, but I'd argue for 99% of the sites out there it won't matter one iota. You can relate this to the whole 'valid xhtml' issue too. I 'get' why developers think it is important, but for the vast majority of users out there it is a non-issue. (Once again, I am prepared to be flamed! ;)
Thanks Ray, but I think you, Raul and I all knew exactly what I meant when I said what I did.
[taps side of nose, and winks in a very unsubtle way]
--
Adam
I know that there are a lot of counter-arguments to this (use what you have available, etc), but one of the reasons that I don't use the cfform, cfgrid, etc is so that I learn how to do it myself.
There may be projects that I work on in PHP and I may need to still implement validation, etc.
Again, I am not against using the tags, I just don't want to see us developers getting complacent (or lazy)
Out of all of them, cftable is the worse. Good luck with making it look good, i.e. odd and even row with alternative background colour (w/o JS that is).
cfform with bind is very powerful and neat, if u don't mind the multiple JS files that comes with it.
Call me old fashion, but I prefer to leave the client side code on the client side, and server side code on the server side.. This is how things start getting sloppy in my opinion. Good practice always keeps these two separated as much as possible. Although ColdFusion may be separating the two behind the scenes it doesn't give me that warm cozy feeling inside.
But for beginners these probably are good to get your footing until you learn other ways..
@Ray: I've never used Flex. Haven't even really looked at it. We've had a corporate policy of "no flash allowed" for ages and I had to jump through a lot of hoops to get an exception in for the grid stuff. :(
I use cfform all the time. The preserve data option is one of my favorite things in CF. Saves me a ton of time.
I do the the validation on the server side and that preserve data feature saves me all the time it takes to repopulate the form with the data the client just entered.
Is there any way to use jquery mobile inside of a cfdiv? When i load jquery mobile on the page and go directly to that page it works fine and the form elements are styled based on jquery mobile's design.. but when I go to the same page loaded inside of my cfdiv on a parent page the jquery mobile code does not render the form correctly.
Code being loaded via cfdiv cannot use JavaScripts in the form of:
function foo() { ... }
and instead must be defined as
foo = function() { }
So to make jQM work inside cfdiv you would need to seriously re-engineer it probably. I would simply skip cfdiv and consider an iframe instead.