Maybe Building The View Last IS The Best Way To Go
I have always been hesitant to try out frameworks like ModelGlue and FuseBox where views are constructed once all the page data has been compiled. I just felt weird about that technique and thought that it was less than optimal in terms of unnecessary data processing. But, as of late, I am feeling like maybe this really is the best choice. What I do like about it is that it truly does divorce the display from the business logic. Now that I am spending a lot of time redesigning the look and feel of a few client sites, I am really feeling the effects of heavily coupled display-logic tiers.
One of the things I have always been concerned about is keeping the ability to use CFFlush. I am adamant about this. Not being able to flush a partial interface to the browser is simply not cool - call it a gut feeling, it's just how it has to be. What I am realizing though, is that blocking CFFlush is really a function of ColdFusion custom tags, not of the page-last rendering. After I compile my data, I can still partiall render my view, then flush to the client, then continue to render my view. I just have to be sure not to use any sort of ColdFusion custom tags for page wrappers (or anything that I might want to call CFFlush in the midst of).
So far, this has been a good year for me and programming epiphanies... and this might just be another one.
Reader Comments
You know, I just had some time to reflect up on my above post and I am feeling that maybe I am to this already to some degree. I run my queries in separate files, I have my form validation in separate files (usually on the file that does the queries also).... my views are sort of divorced from my data compilation.
So, what is it that I am feeling. What is the design flaw that I am battling with right now????
Sorry, this is really stream of consciousness right now :)
@Ben:
One thing to keep in mind about CFFLUSH...
If you're using IIS6's native GZIP to compress output, CFFLUSH will have no affect on the client. This is because IIS will wait for the entire page to process so it can GZIP it and send it to the customer.
(I know this doesn't really have anything to do with your blog, other than it's a CFFLUSH fact I don't think most developers are aware of.)
I've never been able to use ModelGlue or fusebox, mostly because I'm stuborn and I like to do things my way (even if their way is almost completely the same, sometimes it just the little things I can't stand)
With CF8, I've finally made a nice "framework" of my own. You probably wont like it, since you cant CFFlush at all, and I'm sure its a bit slower than others, but it has some theoretical awesomeness that I love.
Suppose we're accessing index.cfm
onRequestStart creates an object called REQUEST.Page.
index.cfm:
The page object loads a layout from an xml file.
It's a real simple file, like this:
<page>
<widget id="head" />
<body>
<widget id="header" />
<widget id="content" />
<widget id="footer" />
</body>
</page>
Then, I create/save my content as xml, and all I insert them as nodes into the widgets in the layout. (The head, header, footer widgets are just outputs from various other objects)
So, now all my content is in an xml document, in a mix of html and my own custom tags.
in onRequest, after including index.cfm, I xmltransform it with my special xsl file, and I get a wonderful XHTML document (that I send as plain html).
What I like about this is that I'm able to make lots of presentational changes quickly, and it's really easy to adapt to new mediums (like mobile, or displaying things as pdfs), just be using a different xsl file.
@Matt, I've seen a number of people doing site templating using XML XSLT (not much in the CF world). I remember some time back doing due diligence on a web agency that had a system doing just that. It's a really popular approach. Only issue I really have with it is that it doesn't allow less technical graphics types to make tweaks to layout so it increases the skill level (and hence cost) of tweaking a layout.
@Dan,
You are right, in that I had no idea about that I had no idea re: the GZIP stuff in IIS. Funky.
@Matt,
I think that is cool, definitely lots of theoretical goodness. I actually used to work with a guy who did the same thing - creating every page as an XML document of some sort and then using XSLT. He did it in PHP and his pages were wicked fast.
@Pete,
I am sure Pete will have more to say about XML-based layouts in the future (Mwaa ha ha ha ha).
That is a good point, although since I work alone, it isn't that critical to me.
Also, in my case, I design things incrementally, and I want each stage to be readable. This would make it possible to hire a graphics guy that only did css.
First I work with ColdFusion until I have an xml file that defines all my content (and I think is very readable)
Then, I work on my XML transform, until I have an html file that is useable without CSS.
Then I write the CSS, and hopefully everything looks perfect.
Being a complete begginer in Coldfusion, I am working with a shopping cart written in CF and Fusebox 3.
I was not sure if this would be the best way to learn CF, but I must say the MVC seperation has certainly allowed me to understand at allot quicker rate than I expected. I find it easier to understand and less visually intimidating to look at and learn from a small piece of the larger picture at a time.
I can only assume that writing small reusable modules would be quicker.
I don't miss the days of designing sites with separate header and footer files. That was awful.
Not being able to use CFFLUSH in those rare cases that I needed it was the one drawback. I'm not sure if any of the frameworks allow you to bypass the layout mechanism, but I lobbied for it in FB3.
Anyway, with the advent of AJAX, that's no longer an issue.
@Patrick,
I think it wouldn't be too easy to take the ideas created in the major frameworks and allow CFFlush. It's probably just a design decision somewhere. I am gonna see what I can come up with. Gotta go examine the other guys, see how they do things.
You could get FB3 to work with CFFLUSH if you took out nested layouts. Of course, that's like throwing the baby out with the bathwater. But there were a few cases where the ability to use CFFLUSH was more important than nested layouts. Theoretically, the framework could have been modified to bypass cfsavecontent and nested layouts on a case by case basis (by manipulating an API variable in the top level fbx_settings file).
You could then turn off cfsavecontent for individual fuseactions, or when a URL parameter is passed, for example.
I vaguely remember FuseQ/FB4 being advertised as working with CFFLUSH. I think it even supported nested layouts in the same request. You just couldn't have a top-level, master layout that contained both the opening and closing html tags.
FB5 allows CFFlush to be used in a much more integrated fashion than FB3 (not sure about FB4.x as we skipped a generation)
cfflush can not be used with cfsaveconetent.
FB5 allows savecontent to be used on a per view or per action controlled by the controller. It does not enforce this.
Therefore something like the following would be possible:
include header view (maybe using cfflush)
do model stuff
include view (maybe using cfflush)
include footer view
..without using content variables at all.
We have used a technique like this in a couple of places where we needed this functionality. Its not as nice as using layouts - esp. as it seems to lead to having presentation layer code (cfflush) interspersed amongst the model code (as its normally the model stuff that will be taking time to process and need to be providing feedback to client)