FW/1 is a great place to start your development from, regardless of the size of your application. That being said, it's no-frills foundation and the fact that it is a very new framework (version 1.1 is just peeking into the sunlight as we speak) means there are scaffolding tools that you may have develop yourself to maximize your productivity. It also means that some of its best features (like nested layouts) can also work against you if you are not careful.
First, I should note that this post makes the assumption that you do know FW/1 well enough to understand some of it's core conventions such as controllers, views, layouts, the "rc" context, and a bit of how FW/1 processing hierarchy works. If not, I'd recommend you visit the RiaForge FW/1 project and give it a try. It is a fantastic framework to develop with, and an especially good place to start if you've never used any frameworks before.
FW/1 by convention can include three levels of layouts for each request. A normal ?action=section.item request can have a /layouts/section/item.cfm (view-specific) layout, a /layouts/section.cfm (section-specific) layout, and a /layouts/default.cfm (global) layout. The layouts are, called and nested in that order, each having a #body# variable that contains the next lowest down. This means that the lowest-scope, most action-specific layout is called first, then nested inside the next-broadest (section) and then finally the site-wide (global) layout. This allows for some flexible layout schemes, and more-so allows you to also include CSS/JS-specific includes for a particular view or section. This, however, is where it gets tricky.
Say for instance I am using jQuery and the jQuery UI framework. I know that generally speaking I am going to want to include jQuery and the application's global CSS stylesheet on every page, that on pages with jQuery UI elements I'll need the UI's CSS and JS files linked, and that on specific views I will need to reference view-specific JS/CSS setup files to configure my jQuery UI elements. One of the easiest ways to do this is to use FW/1's view() method in combination with the <CFHTMLHEAD> tag, like so:
and the view it references:
This essentially has my layout reference a view that contains view-specific header information. The encapsulating section- and global-level views can do the same, including broader-used CSS and JS files. It's a good way to both organize your code and only include the files that are specifically needed for a section or view.
There is, of course, a catch ... and it is a big one. The fact that I am calling <CFHTMLHEAD> in my "include" views means that these are triggered right away ... not by the FW/1 hierarchy. The contents of each of these views is immediately added to the ColdFusion page structure, and is done in the order they are requested. The result is that while your layouts are nested in the order you expect, your <CFHTMLHEAD> references have been reversed. This can obviously greatly affect your jQuery applications, especially if jQuery ends up being called *after* all of your jQuery code is linked to your page (the browser will process these files in the order it finds them, leaving your carefully crafted jQuery dead and without an engine to run it).
Because I like the structure of referencing my CSS/JS files in the views that will use them, I wasn't willing to let this lie. To solve the problem, I used the global "rc" context to add a "HeadLoader" methodology that works quite well.
In my controller:
... and my modified 'include' view:
...and finally in my Application.cfc:
Basically what I have done is created an array in the rc (Request) context called "headLoader" that all layouts will have access to. As each layout calls its "include" views, the contents are pre-pended into the "headLoader" array. Finally, when all layouts and views have been processed, the Application.cfc onRequestEnd() function fires. A simple loop over the "headLoader" array loads all of my <CFHTMLHEAD> content in the proper, nested-layout order (you may notice this is referenced as request.context, which is the same as the globally shared "rc" context). I find this perfectly encapsulates my files so that only the required ones are included on a given page.
Perhaps a future version of FW/1 will have a dedicated methodology for exactly this sort of functionality, but to tell you the truth a part of me hopes it never does. There is a real beauty and elegance in FW/1's simplicity. It covers the basics of what a Framework needs to be really well, and we already have enough Swiss Army frameworks available that it would be a shame to have FW/1 bloat into another.
If you haven't tried it yet, I'd strongly recommend you visit the RiaForge FW/1 project and give it a whirl.
Apr 21, 2010 at 4:56 AM Nice1! I've worked around this problem myself yesterday, whilest using the fw/1 plugin template for mura... It worked out great, but I will be using this solution next time!
Jul 28, 2010 at 4:21 AM Just out of interest, is there a particular reason you chose to prepend rather that append to the array?
Jul 29, 2010 at 11:10 AM @Seb, the whole idea of this methodology is that it reverses the order the headers are inserted, as the layouts are called in narrow > global order. I suppose I could have reversed this in the onRequestEnd instead.
I'm at CFUnited right now, so maybe I'll chat with Sean about this directly (not that I haven't already bothered him enough as it is).