Stephen,
Your questions deserve a much more thorough analysis and response than I
have time available for, but I'll try to hit some of the high points.
We haven't evolved an 'AdvantaBox' methodology into which all our coding
is shoehorned, in the first place. That would elevate the development
methodology to a higher priority than optimizing the applications we
build. Instead, we put a lot of thought and analysis into defining the
requirements of an application first, and defining how the application
will meet those requirements second. Only then do we design and build
the application. Fusebox is a one-size-fits-all design methodology.
While it is flexible enough to work acceptably in most situations, and
there are even a few situations in which it is probably preferable to
use it, it is a mistake to 'put the cart before the horse' and apply a
single design methodology to every application one builds. I'm not
disputing that there may indeed be advantages to adopting a single
design methodology for every application a company builds; the problem
with that approach is that the advantages gained do not necessarily have
anything to do with optimizing the performance of the applications being
built. And application performance should win such contests every time.
Example: the Fusebox specification calls for putting queries into
separate templates having filenames beginning with "qry_". While
modularizing code is a very smart thing to do, it can be overdone. We
would only put a query into a separate template if that query was used
in more than one place, and would never blindly put it into its own
template just to follow some arbitrary design methodology. It's the
same with action ("act_filename.cfm") and display ("dsp_filename.cfm")
templates. It's not really likely to be the best approach FROM THE
PERSPECTIVE OF THE APPLICATION'S PERFORMANCE to modularize them unless
they are going to be re-used elsewhere. Why would anyone want to
deliberately program extra delays (it doesn't matter if they're only a
few milliseconds apiece, that's not the point) into their applications
with unnecessary CFINCLUDEs on every page hit merely for the sake of
adhering to somebody's design methodology du jour? If your clients knew
that's what your priorities were, they probably would (and should) fire
you.
Another example: ColdFusion attempts to automatically include an
application.cfm when .cfm's are called. If it doesn't find one in the
subdirectory of the template being run, it searches up the directory
tree of the application until it does (or eventually doesn't) find
another application.cfm to use. Since you can't tell CF to not do this,
using app_locals.cfm (and app_globals.cfm) instead of application.cfm
doesn't stop CF from hunting for application.cfm, thereby increasing
processing time. The very minor advantage gained by using
app_locals.cfm and app_globals.cfm as CFINCLUDEd files for the
occasional benefit of CFMODULE wastes processing time unless the
Fusebox programmer uses an application.cfm anyway! So why not just
employ application.cfm in the way it was designed for use by Allaire and
skip the extra processing required by using app_locals.cfm and
app_globals.cfm?
I think the bottom line is that if Allaire thought Fusebox was a better
way of programming in ColdFusion, that they would wholeheartedly
recommend its use and redesign ColdFusion to work better with it.
Regards,
Karl Simanonok, staff consultant
Advanta Solutions, Inc.
Original Message:
============
Date: Tue, 7 Nov 2000 19:49:11 -0800
From: "Stephen M Aylor" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Subject: Re: fusebox
Message-ID: <018401c04936$db2bb430$0e01a8c0@iindev>
<snip>
So what were your alternatives??
What werkz better?
How would you improve the file naming conventions?
What would you keep?
Please tell me it sucks for a better reason the the file naming!!!?
Also...
I dont recall there being a giant plea/demand/cry - to run out and
re-write
everything one does or did in FB? .... and FAD? Javascript animations
...
now theres a FAD.
Stephen M. Aylor
iiinsurex
------------------------------------------------------------------------------------------------
Archives: http://www.mail-archive.com/[email protected]/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists or send a message
with 'unsubscribe' in the body to [EMAIL PROTECTED]