Jen asks:
As I said in that post, I'm not really a fan of cfhtmlhead so I may not be the best person to ask. I'll explain how I think it could be used.i read your recent post on the cfhtmlhead tag and wondered if you might review why we would use the cfhtmlhead tag instead of a cfinclude? what are the pros and cons for each method?
Imagine a fairly typical ColdFusion page that looks like so:
<cf_layout title="Deep Thoughts by Paris Hilton">
code and logic for page go here
</cf_layout>
This this page, the main logic/text/etc of the page is wrapped by a custom tag that handles the layout of the site. Imagine your code/logic/etc realizes that it's going to need Spry libraries. But at this point, the head of your template has already been output. In order to 'change the past' so to speak, you could simply use cfhtmlhead to embed the script tags to load Spry libraries.
Now normally I wouldn't do it like that at all. I'd have something like this instead:
needSpry = false
if (logic here) needSpry=true
<cf_layout loadSpry="#needSpry#">
etc
</cf_layout>
And in a Model-Glue style framework I'd do it like so:
if(logic here) viewState.setValue("needspry", true)
Which the Layout event would be able to pick up on.
Archived Comments
A lot of times I find myself using cfhtmlhead when maintaining someone else's application. Let's say for instance you have a one off javascript or css rule that needs to come into play and you're too lazy or unable to modify the template of the page. cfhtmlhead can come to the rescue and dump it up in the header.
Theres other, more valid, uses cases but ones like those I seem to come up against a lot.
Admittedly in the past I have abused the functionality provided in the tag, mostly in the same way as Danak described. I would find myself including js/css using cfhtmlhead on the page that is going to need the functionality.
However from a front end engineering standpoint doing things like dynamic js and or css with the use of cfhtmlhead is a performance nightmare as your stripping the browsers of their ability to cache resources they should really be able to.
A trap I fell into often was using CF to generate javascript dynamically where more appropriately I would have made my JS more dynamic to accommodate my CF.
My big use case is customtags. Let's say I build a javascript+html interface, and the javascript is only used with this custom tag.
I'll write the javacript into the custom tag, but load it into the htmlhead instead of inline. That way I keep all the code in one place, but I maintain the javascript in the header instead of the body of the html page.
I don't know if it is a compelling use case, but it's why I use it.
Similar to Terrence, I find that the single best reason for using cfhtmlhead is when dealing with Javascript libraries and dependencies.
In my recent applications, I'm almost always using a "scriptDealer" service object that allows me to call <cfset controller.dealScript(scriptname[,script_text][,script_priority])> to create the final block of javascript files served in the head section with the HTML output.
For me, that results in only having to use cfhtmlhead once in the request and allows me to ensure that if I need a dependent library, I can can call it repeatedly and it will only be served once and in the correct order for dependency tree. An frequent example, in my case, would be when using JQuery plugins like the UI components (accordians, tabs, etc.).
My 2 cents. :)
I use it for custom tags that invoke jquery functions.... for example, cf_dragDropList would do something like:
load jquery core, if not already loaded (don't load it twice)
load jquery ui components is not already loaded
load JS required to make drag and drop list sorting work
specifics are made dynamic by passing css classes and ids to the cf_dragDropList as arguments. So I can crate a drag and drop sortable list that saves via ajax with a single custom tag.
cfhtmlhead makes this possible.