There's actually an excellent reason for distinguishing between display
files and layout files. Layout files are applied AFTER the display files.
These act like a "skin". In fact, skins (called "layouts" in FB3) can be
nested. Say that we have a site with a directory structure like this:
MyApp
-- Admin
-- Users
The fuseaction Users.new might create a generic form. Then the directories,
Users, Admin, and MyApp, all can apply a "skin" in Chinese doll fashion:
Users wraps the login form; Admin wraps that and then MyApp wraps that.
This can be turned on/off for individual layers. In addition, because the
layout presentation is applied after the content is generated, the layout
chosen can be determined based on what occurs in the content. This provides
a great deal of power and allows presentation to be quite separate from
content.
For reasons that elude me, some people devote great energy to bad-mouthing
Fusebox. When you ask them, it almost always turns out that they have never
actually used Fusebox. Fusebox is about empowering developers, not about
advancing a particular brand of religion and so I recommend that people
evaluating Fusebox talk to developers who actually *use* it.
Original Message:
-----------------
From: Sean A Corfield [EMAIL PROTECTED]
Date: Thu, 29 Aug 2002 11:00:45 -0700
To: [EMAIL PROTECTED]
Subject: Re: FuseBox vs Macromedia Programming Standards
On Thursday, August 29, 2002, at 07:07 , Jeff D. Chastain wrote:
> I did not study it for details, but what I read of the coding standards
> link
> you mentioned sounds like primarily just good programming practices - i.e.
> naming conventions etc.
Correct, it is a list of recommended best practices.
> FuseBox has some of this, but FuseBox is really
> more of a design architecture.
It's a framework.
> There was a mention on the below mentioned
> site that separating content from layout is a good idea
Indeed it is.
> FuseBox actually implements this.
No, Fusebox recommends you do it and provides a well-defined way for you
to do it. Fusebox itself does *not* implement this for you - you have to
write your code in a very specific manner in order to do this. Fusebox
again provides a *convention* for it - HTML generation goes in dsp_xxx.cfm
files or layout files (which, confusingly, are two separate things in
Fusebox), database queries go in qry_xxx.cfm files, actions (logic) go in
act_xxx.cfm files. It's somewhat contrived and, IMO, somewhat unnatural.
All it's doing is forcing you to partition your code, it isn't creating a
tiered architecture like MVC for example.
> There was also a suggested documentation format mentioned
> that should be provided for each template. FuseBox is a 'generation'
> ahead
> of this by utilizing a documentation standard called fusedocs that are
> actually written in XML to allow for later processing.
Again, it is a very stylized approach, requiring users to learn a specific
way of documenting code (which is not necessarily a bad thing) and it
still doesn't help ensure that the documentation actually matches the code.
I won't argue with the benefit of being able to automatically generate
documentation from code - which Fusebox effectively lets you do - but this
is an idea that's been around since the 60's so it's nothing new.
ColdFusion MX supports this directly by generating Javadoc-style output
from the code itself which means that the documentation can *never* get
out of sync with the code, unlike Fusedocs.
> To sum up, the below link provides a lot of good information in terms of
> 'best practices'. FuseBox itself is a program architecture that takes
> those
> 'best practices', improves on them, and puts them into work.
Fusebox is a framework, not an architecture, and whether it "improves" on
various best practices is a point of much contention.
> http://www.corfield.org/coldfusion/codingStandards.htm
See also:
http://www.corfield.org/coldfusion.phtml?cfsection=coldfusion/fusebox
"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood
______________________________________________________________________
This list and all House of Fusion resources hosted by CFHosting.com. The place for
dependable ColdFusion Hosting.
FAQ: http://www.thenetprofits.co.uk/coldfusion/faq
Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
