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
-----Original Message-----
From: Karl Simanonok [mailto:[EMAIL PROTECTED]]
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.
...
IMPORTANT NOTICE:
This e-mail and any attachment to it is intended only to be read or used by
the named addressee. It is confidential and may contain legally privileged
information. No confidentiality or privilege is waived or lost by any
mistaken transmission to you. If you receive this e-mail in error, please
immediately delete it from your system and notify the sender. You must not
disclose, copy or use any part of this e-mail if you are not the intended
recipient. The RTA is not responsible for any unauthorised alterations to
this e-mail or attachment to it.
------------------------------------------------------------------------------------------------
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]
