Rob Wilkerson

So now that I've been using it - or, if I infer correctly, at least some bastardization of it - for a while now, I decided to write my first pod for Ray Camden's oh-so-prevalent BlogCFC blogging package just to see how it worked.

Aside from the functionality of the pod itself, I had a few primary goals:

1. Keep all functionality completely self-contained.  In other words, no changes to the core BlogCFC code base.  Multiple files are fine as long as they can be stored logically within the structure defined by the existing package.
2. Produce semantic markup with no inline styles for easy customization and maintenance.
3. Produce standards-compliant code when rendered.  I don't know if this is a current or future goal of Ray's, but I didn't want my pod to be the reason someone's site didn't validate.  Besides, standards are something I care about.

The first two of these were pretty easy to accomplish by simply following best practices.  Then I hit a bump in the road with the third. For this pod, I wanted to include some minimal styling because the pod includes a hierarchy of links and I wanted to distinguish one type of link from the other. 

The easy path, of course, was to create inline styles.  They're self-contained within the pod and strictly compliant, but...oops.  Not so good for the separation of content from presentation and, therefore, bad for customization and maintenance. 

My next thought was to create an embedded style sheet within the pod code.  That would satisfy all three requirements if I stored the style sheet content in a variable using cfsavecontent and then wrote that content to the head of the parent page using cfhtmlhead.  Perfect.  Except that it didn't work.  When I cleared the cache using the reinit parameter it looked great.  It still looked great when I reloaded (without the reinit parameter).  The next time I reloaded, though, my pod was completely unstyled.

After digging through some code, I found that BlogCFC caches the complete source code of the homepage (the page I was using to test) - presumably for performance.  Content added to the head using cfhtmlhead isn't cached with the rest of the source code.  The cache is created using thisTag.generatedContent so the content added by cfhtmlhead just isn't available.  The same issue would arise if I put the CSS code in a source file.  I'd still need to get a link to that file in the head of the page.

Even with this (major) flaw, the embedded-style-sheet-written-to-the-head was the best solution I could come up with so I created a quick block of cache-injection code in my pod.  If the homepage cache exists when the pod is rendered and hasn't already been injected then the pod code injects its style sheet content into the cached source code.

Now everything works as intended except in one known test case:  If I load the homepage using the reinit flag, then immediately load the homepage twice more without the reinit flag (yes, that's also the original test case).  Grrr.

Turns out that the first time the homepage is loaded, the cache isn't created at all.  The second time - without the reinit flag - the cache is created.  The third time (and every subsequent time, of course) the pod is never rendered because the homepage is generated directly from the static cache.  That means that the pod has no chance to inject its embedded (or external) style sheet into the homepage cache.

I don't have a good answer for that.  The workaround is to load the homepage and then load a blog entry (or any other blog page, as far as I can tell).  Pages that aren't the home page don't get cached as thoroughly and the pod is rendered with each request.  The first of these non-homepage requests will perform the cache-injection. Any any future visits to any page will render properly because the styles are now part of the cache.  Not great, but it's the best I've got at this point.

If anyone has any thoughts on this, I'd love to hear them.