Writing Compliant Code with ColdFusion

Technical

Anyone who's ever worked with me or for me will probably agree that I can be pretty seriously OCD when it comes to my code. I believe in standards, I believe in readability, I believe in maintainability. I'll spend more time than I probably should making sure that, once my code works, it's also pretty. Some have called it anal-retentive. They're right, but I'm sticking with OCD because it sounds better.

When I say that I believe in standards I mean web standards as well as code formatting standards. A post on cfsilence reminded me of how I have used ColdFusion to help produce compliant code.

In a previous life, I worked on a product that relied on a distributed content model. Output modules were pulled from all over the place and compiled into a single rendered page. Each of these modules were completely independent of each other except for the fact that they appeared together on the same page. This meant that none of the modules had their own head or body tags. Because most of this code dated back to 2000/01, the general response to a need for styles or scripts was to just drop an embedded style sheet in with the rest of the markup output.

The result was a rendered page with style and script tags scattered throughout the markup code. Ugly, at best. Ugly and non-compliant at worst. But then a buddy at Adobe reminded me of the cfhtmlhead tag. Doh! How had I managed to so completely forget about that one?

Coupled with cfsavecontent, I managed to rid myself of one standards-related problem very quickly indeed:

It still wasn't as pretty as I'd like, but at least all of the module-specific styles and scripts were consolidated and located within the head tags. That's progress...right?

 
I like that approach Rob. In thinking about our Mach-II applications, it seems like it might be a good idea to just create an event arg (think request variable) that can be appended to throughout your application, so in individual views that make up a composite view you could just append any necessary scripts to it as you go. Then in the layout view always have a

Hmmm.... off to re-factor. :)
 
posted 975 days ago
Add Comment Reply to: this comment OR this thread
 
 
I'm not familiar with machII, but that sounds like the same practice I applied in this effort. I had no way of knowing how often a content module may appear on a page and I didn't want to include the same style/script blocks multiple times, of course.

The answer was to just set a request variable. When the module rendered the variable was checked. If it didn't exist, the style/script blocks were written to the head. If the variable existed, those blocks were ignored. If I understand you correctly, that's essentially what you're thinking and it did exactly what I wanted it to do.

No more page bloat due to style/script duplication. :-)
 
posted 975 days ago
Add Comment Reply to: this comment OR this thread
 
 
oops... forgot my cf block would be cut out. Now with square brackets!

[cfhtmlhead text=#event.getArg("HeadContent")# /]
 
posted 975 days ago
Add Comment Reply to: this comment OR this thread
 
 
If memory serves, one of our legacy developers had written his own head content capture tag that was a manual version of cfhtmlhead. He captured the content between the start and end tags of his custom tag and wrote it all to a request variable. Our rendering engine then wrote the content of that variable to the head of the rendered page. It worked, but it wasn't as clean as cfhtmlhead and it wasn't implemented as often or consistently as it should have been.

Having a native tag that is fully documented makes it easier to remember to use it. Well, except that I had forgotten it. Leave it to me to blow my own argument.
 
posted 975 days ago
Add Comment Reply to: this comment OR this thread
 

Search

Rob  Wilkerson