There are two issues that need to be addressed when looking to implement such a solution. CF locations and dependent content areas . . .
There is no point starting to render a page that you won’t end up displaying. If someone just filled out an admin form you have no idea whether you’re going to cflocation to a list with a “success” message or redisplay the form with an error until you’ve processed the form.
Dependent Content Areas
Content areas are not always independent. I first came across this problem when I developed a system back in the 90’s where users logged in and I couldn’t figure out why it still said “Hello Guest” in the top bar even though the user had just been successfully authenticated. Refreshing the page solved the problem. After a while I finally figured out that because I was rendering the page sequentially, at the time the top bar was rendered, the user hadn’t been authenticated yet, so it was displaying the wrong content (it should have been “Welcome #FirstName# #LastName#”) until the page was refreshed. You can come across similar problems when you have a shopping cart “number of items” in the topbar or sidebar that (depending on your site layout) could be rendered before the main content area.
A Pragmatic Approach
I’m with Ben in that all of the applications I develop (I don’t do portals) have a primary dynamic content area and then 0..n secondary dynamic areas. When you play with this problem for a while you realize that all you need to do is to run the controller for the primary content area before you start rendering the page. You can then render the page top down and your render methods for the other dynamic content areas just call their own independent controllers (which still have access to a request scoped object, session data and the like) to call the model to get the data to populate those content areas.
I don’t know that I’d go to too much trouble to “solve the cf flush problem” as it smacks a little to me of premature optimization. However, it just so happens that the requirements to solve this map pretty well with the way the LightBase rendering engine and controller were going anyway, so I’m going to drop in support for flushing partial page content within the framework. In my experience it is usually the primary content area that takes most of the processing time, so I’m not sure I’ll gain much, but there doesn’t seem to be much of a downside and it is interestingly a return to the old component based (as opposed to page based) MVC apps I used to write in VB and the new ones that people are starting to write in Flex.