Lee,
Thanks, I was getting ready to do the same thing. I wish
people would try Fusebox before they just bash it. There is
a GREAT network of some of the BEST CF developers in the
world that are on the Fusebox email list. If you have
questions, concerns, or what ever join that list and learn
about it. I think that most people, not all, but most
people that go bashing it, one don't really understand CF,
and two, don't understand Fusebox at all. In short, join
the list, read the book, download the tags and samples and
take an hour and learn it. It's really not all that hard to
figure out.
Just my .02
Bill
<cf_warrior>
-----Original Message-----
From: BORKMAN Lee [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, November 08, 2000 9:49 PM
To: CF-Talk
Subject: RE: fusebox
Thanks for the detail, Karl.
I must disagree with your basic point, though. You say that
"it is a
mistake to put the cart before the horse and apply a single
design
methodology to every application one builds". If the
alternative is to
develop a new strategy tailored to each individual project,
then that sounds
like bad news.
I'm the first to admit that FuseBox is not a perfect
methodology for every
occasion, but I would always prefer to adapt a single
methodology, ANY
single methodlogy, always provided that it is 'sufficiently
flexible' and
not too cumbersome. FuseBox is the only candidate that I
have yet seen for
a CF methodology/architecture that satisifies my minimal
requirements of
usability and flexibility, so I am very happy to use it.
In short, I disagree with your list of priorities:
1: application performance
2: maintainability
3: cost of development
I ALWAYS put ease of development and maintainability BEFORE
application
performance, and my clients would be horrified if I did
otherwise.
Performance issues are usually most economically addressed
by enhancing your
infrastructure (CPU power, RAM, bandwidth), not by squeezing
millisecond
gains from CF file accesses. Developer time might cost
between $100 and
$300 per hour. For one hour of developer time, then, I can
double the RAM
on my production server, and achieve substantial performance
gains.
To summarize, I PREFER to squeeze everything into one
architecture/methodology, even though that methodology is
not perfect. This
makes our applications maintainable, enhancable, robust,
understandable, and
inexpensive. On the odd occasion that performance criteria
are so rigorous
that our standard methodology can't handle it, then AND ONLY
THEN do we
modify it. Re-inventing the wheel each and every time is
bad for everyone,
devlopers and clients included.
As for your detailed criticisms. Breaking your code into
pieces BEFORE you
know you are going to re-use the pieces is one of the GREAT
benefits of
FuseBox. It's incredible how much you can end up re-using,
when the pieces
are already there. If you wait until an opportunity to
re-use becomes
obvious before breaking up the code, then developers are
discouraged from
re-using and they might decide it's easier to cut and paste.
I really don't mind much if people want to use
application.cfm instead of
app_globals.cfm. I use application.cfm just to check that
all requests are
going through index.cfm. This also prevents the server from
searching
endlessly up the tree.
So, I don't think FuseBox is the "methodology du jour". In
fact, the only
credible alternative architecture/methodology I've seen is
CFOBJECTS, which
is even MORE heavy on file accesses, and has a much steeper
learning curve.
Anyway everybody, if you haven't tried FuseBox, give it a
go, and don't be
put off. It's true that some people don't like it. For the
life of me,
though, I can't see why.
Lee (Bjork) Borkman
http://bjork.net ColdFusion Tags by Bjork
------------------------------------------------------------------------------------------------
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]
