HTML in Application.cfm

The CF_Talk list recently had a discussion about whether it is acceptable to put HTML in Application.cfm. I thought the topic was a very worthy one, but ended up shedding as much heat as light.

I will do my best to shed some light on the topic.

In the short-run, putting HTML in Application.cfm (or including HTML from Application.cfm) can speed up development. If your project ends up changing over time (as most do), however, this can lead to code that is difficult to maintain.

This approach causes problems when different pages have different layouts. For example, a pop-up page would use a different layout than other pages on a site as might the home page.

A common solution is to use a different directory for pages with a different layout so that you could use a different Application.cfm. This makes it slightly more difficult to make common, site-wide logic available to the pages with alternate layouts. The difficulties are more pronounced for a home page with a different layout. Putting every other page in a different directory is impractical.

You could have Application.cfm decide which layout to use based on the file name instead. For example, index.cfm might have a different layout than other files. This is problematic when you or your client want to make a quick copy to test a change.

For example, you might copy index.cfm to index2.cfm at which point the correct layout is no longer being used. Or, perhaps the client might want an alternate home page. Yes, you can always edit Application.cfm with the new file name, but it is counter-intuitive. People expect a copy of a page to look the same as the original.

In fairness, one advantage to including HTML in Application.cfm is that it makes including one page from another very easy (whether or not that is a good idea is another discussion).

On the flip side, it is possible that a client might want part of the layout to change based on which page is being displayed. If you were including the layout code from the page, you could set a variable above the call to the layout to indicate this and perhaps to make some data available for that purpose. If you were including your layout from Application.cfm, that is one more file name check that you have to add to Application.cfm.

These extra bits of code in Application.cfm may not seem like a big deal, but over time they add up to confusing code that is difficult to maintain.

Good luck!

Comments (Comment Moderation is enabled. Your comment will not appear until approved.)
I'd have to really caution against this approach. It can cause some real layout problems. I think the most common issue is that many people wind up with output in a page occuring before the DOCTYPE directive. This can cause real headaches if you use css to do any layout as this will change the way particular browsers render the page. In IE, it generally triggers a change from standards mode to quirks mode (I think).
# Posted By Mike Rankin | 1/5/06 4:41 PM
Mike,

I'm not sure I follow you. What approach are you cautioning against?

I am arguing (perhaps not very well) against including any HTML in Application.
# Posted By | 1/5/06 5:27 PM
Oops. I thought you were trying to make a case for putting output in the Application.cfm page.

In the immortal words of Gilda Radner:

Nevermind.
# Posted By Mike Rankin | 1/5/06 8:20 PM
Just goes to show that my writing still needs lots of work (which was basically the impetus for this blog in the first place).

; -)
# Posted By | 1/6/06 2:57 PM
I'm definately in the "no output in application.cfm" camp, although I wouldn't cite the doctype appearing below content as a reason, since, if I were going to put content in application.cfm (which I'm not) I would put the doctype there also. But in general, I think putting output in the application.cfm lacks flexibility over other approaches. That being said, I actually do put output "directives" in the code in the application stage of my framework. That is to say, information about what may or may not be displayed in the body of the page, but never actual output. The structure of the framework, automating the execution of nested directories of code during the application (or onRequestStart) stage of the request actually helps to provide an easy way to alter the content for individual pages (the home page that varies from the remaining site) or entire sections of an application (a popup <> directory). The fact that these nested directories are executed automatically keeps me from placing any template logic in the Application.cf(m|c) and at the same time allows me to quickly and accurately affect any given page or all the pages within any given directory based on my current need.
# Posted By ike | 1/6/06 10:11 PM
Well said Ike.

I don't follow what you mean by output "directives" however. Could you expand on that or let me know where to find more information about that?
# Posted By | 1/8/06 3:31 PM
BlogCFC was created by Raymond Camden. This blog is running version 5.8.001.