> 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.
I guess that part of my problem with Fusebox is that I'm not exactly sure
what you'd call it.
Is Fusebox a methodology? I don't think so. All it does is tell you how to
organize your code. That's not a methodology. It doesn't really address the
design process. It doesn't address the process of application development.
All it does is tell you where to put code.
I found this to be interesting reading about methodologies:
http://www.martinfowler.com/articles/newMethodology.html
Is Fusebox an architecture? Again, I don't think so. All it does is tell you
how to organize your CFML code and HTML markup. It doesn't address how to
structure your data schema, or how to access that schema effectively. It
doesn't tell you how to partition application logic - in fact, it
discourages the partitioning of application logic a bit, if you buy the
whole thing, with its focus on portability across databases.
So, what is it? I'm not really sure. I do know that when I build a CF
application, my problems don't come from organizing my CF code, or even
getting optimal reuse value from that code.
> 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.
In general, in the broadest sense, I'd agree with this. There are lots of
specific places where I'd disagree, though.
For example, you could do everything with simple HTML forms; from a pure
maintenance perspective, that's obviously best. However, you can make your
applications better in some cases by adding complexity, in the form of
things like JavaScript and frames, etc.
I also don't believe that using Fusebox really affects maintenance costs all
that much. I've done maintenance on plenty of applications, with and without
Fusebox, and haven't found it any easier to maintain the Fusebox ones. CFML
scripts generally just aren't that complicated. As long as the original
developer uses some common-sense file and directory organization, a
competent CF developer won't have trouble maintaining the application.
> 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.
This, to me, sounds like a flaw in the design process. During that process,
you should be looking for what can be reused and encapsulating it. This
shouldn't be something that you find out halfway through the development
process.
If everything is mindlessly broken into the smallest atomic pieces, what's
the point? Do you build every line of code with the idea that it will be
reused? Of course not. You identify algorithms and separate processes, and
build components to encapsulate them.
> 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.
I'm not convinced of the need for a CF-specific development architecture at
all. Again, the simple application of common sense will do fine, instead of
having a "rulebook". The point of using CF is that it's a high-level, simple
CGI programming tool. It doesn't warrant architectural rules. If you want to
build an application architecture, you'd be better off spending more time on
application partitioning.
> Anyway everybody, if you haven't tried FuseBox, give it a go,
> and don't be put off.
I'd agree with this wholeheartedly. Try it for yourself. If you like it,
good for you! If you don't, don't feel like you have to use it because it's
a standard - it isn't, in any meaningful sense.
> It's true that some people don't like it. For the life of me,
> though, I can't see why.
Funny you should say that. I don't see why people like it so much, myself. I
guess I'm just crazy, though.
Dave Watts, CTO, Fig Leaf Software
http://www.figleaf.com/
voice: (202) 797-5496
fax: (202) 797-5444
------------------------------------------------------------------------------------------------
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]
