views:

82

answers:

5

I want to:

  • on every page,
  • check if a file exists
  • include that file if TRUE

i.e.:

 <cfset variables.includes.header = ExpandPath("_inc_header.cfm")>
 <cfif FileExists(variables.includes.header)>
   <cfinclude template = "_inc_header.cfm">
 </cfif>

Is this a good idea?

edited to use just "_inc_header.cfm" as the template

Alternative practical use would be something akin to this PHP code:

foreach (glob("includes/*.php") as $inc) {
   require($inc);
}
+1  A: 

Depending on traffic, there could be a bit of a performance hit.

Could you put the include statement within a try/catch or failing that, maybe save the result of the check in a session and then just do the check once per file per session?

Sam Nicholson
I could do the try/catch, would you happen to know if a failed <cfinclude> is faster than a FileExists?I don't think I would save the value in a session unless it was an array of header paths that do exist. And then I would have to find a value in an array, which doesn't save anything, does it?
davidosomething
Depends on amount of files I guess. I think try/catch would probably be best as it is just making one call to the file and running it if its there which is what you're aiming for. By doing the check and then including it, it is making two hits.
Sam Nicholson
Be careful with a try/catch approach in a situation where it will throw an exception in a significant number of cases. (And significant could even be as low as 10% if you're under heavy load.) Exceptions take a significant amount of time to throw and catch, and can be a significant bottleneck in your application. I would apply liberal caching, if you do go with your fileExists() approach; though I'd cache in the Application or Server scopes, not Session.
Adam Tuttle
A: 

i think a better way is to just check for the existence of the header variable in the variables.include structure:

<cfif structkeyexists(variables.includes, "header")>
  <cfinclude template = "#variables.includes.header#">
</cfif>

if a page isn't going to use the header then in your page code remove the header:

<cfset structdelete(variables.include, "header", false)>
rip747
Current architecture is like this, and is what i'm trying to improve upon, stated previously.
davidosomething
A: 

Question: how would you cfinclude the file with absolute file path returned by ExpandPath("_inc_header.cfm")?

Any way, your question should sound like "ColdFusion speed cost of ExpandPath + FileExists", because two functions invoked each time.

Can't help you without benchmarking, but it is possible to use something similar to the proposed by rip747. But I would collect the available header files on some early phase (at least at application start, maybe in development process) and used that collections for checking. Collection key can be the current directory path, or maybe unique subsection code if available.

Sergii
edited code in original question, not using absolute path, using the _inc_header.cfm file in the same path as the page calling the template.
davidosomething
A: 

I would probably create an application variable called application.header, and put in the html from the header.

Then in each app, I can check for both isdefined and if not null.

For example:

In application.cfm

<cfparam name="application.header=" default="">
<cfset application.header="<img src=/images/logo.png alt='Logo' border=0>" />

In your app page.

<cfif isdefined("application.header") and application.header gt "">
<cfoutput>
#application.header#
</cfoutput>
</cfif>

And there you go..

crosenblum
A: 

I used to think like you do but I also heavily monitor my execution times. Since changing to a system that calls FileExists several times per request I've notice 0ms difference in the milliseconds required to load pages. It's entirely probable than any frequent lookup on a given file will cause it to be cached somewhere in the system or SCSI drivers or drive hardware. It's even more likely that lookup times on SCSI hardware are sub-millisecond.

Given I use cfinclude heavily it's no surprise that one more lookup doesn't even show on the radar.

The reality is it would likely have more overhead than a variable lookup but we're probably talking 0.0001 milliseconds difference unless you have millions of files in a directory or you're running a webserver off IDE disks or something silly like that. The additional code complexity probably isn't worth the savings unless you're /. or Apple or something.

To those who say it's poor architecture I beg to differ. In the mid to long term you can buy processors far cheaper than developer time. Having a system that requires only changing files is simpler than changing files AND variables - and dealing with the additional complexity. Like most things in the optimization category many tasks that save a few MS may occupy hours that could be spent on more effective measures like improving your cache.

SpliFF