> Amen to that, i have been using fusebox for a while now, and my
> opinion is that it is another layer of stuff on  top of what you
> already have to do.

When you get down to it, any methodology is just "another layer of stuff."
Fundamentally, however, a methodology is an attempt to superimpose an order
or structure to code. Although it would be nice if a methodology decreased
the amount of work a single developer had to perform to code a given
application, a methodology usually has some loftier goals such as
synchronizing disparate developers on the same team, quality assurance, code
documentation, etc.

It's been my experience that the larger the project, the better Fusebox is
at accomplishing these goals. If, however, you are simply adding a guest
book to a relatively static site, then Fusebox would add quite a bit of
overhead and development time while gaining the developer very little, short
term or long.

> I think i would p[ersonally tone down the fusebox methodology myself,
> it needs to be alot less complicated to trully be a catch all
> solution.

Many people, myself included, have adopted pieces of the Fusebox
methodology. How much you adopt, if any at all, is up to you.

> When the fuse breaks its maddening, and is just another layer to run
> through to fix stuff.

Debugging a Fusebox application takes a little getting use to (like an hour
:), but I prefer it to other attempts I've seen which try and make the best
use of code through reuse. A Fusebox application has one entry point and one
exit point. All the developer has to do is trace the path of the FuseAction.
The only time I really run into problems is when I have several included
query templates in a row and I get a cryptic ODBC error message and a
ColdFusion "Problem occurred in tag <CFQUERY> at or around line 1...." Then
it takes the extra step of aborting processing of the page a couple times to
determine which query is in error.

> And i don't buy the whole makes it easier to bring in other
> programmers, because almost all of them will have to learn fusebox
> and the particular way its used where they are working.

I don't think you're being asked to buy anything. :) We require that our
programmers be familiar with Fusebox and to be able to code in a manner
similar to Fusebox. The same was true at the last place I worked where I was
head of production. This is, of course, not a requirement to getting hired,
nor do we code all our applications in this methodology. But we have found
that it works very well on larger projects with several different
specialized developers and teams working on dedicated tasks. With many a
notable exception, most programmers/designers/DBAs I've met and worked with
seem to like the style, which is always a bonus. But of course, this is a
highly subjective generalization. :)

> I still like the idea of a methodology, im just not sold on fusebox

As someone already noted, it is not necessary to like or "buy" fusebox, but
it is necessary to choose a methodology. Even if your methodology changes
from project to project (and hopefully it will evolve), routinely dealing
with reoccurring problems in the same manner and being able to expedite the
daily chores of programming is essential.

In regards to Fusebox, it doesn't hurt that some very talented and
experienced ColdFusion programmers have tackled these issues already. That,
to me, is one of the greatest benefits of Fusebox. Although we don't need
many aspects of the Fusebox standard, they already exist and are freely
available for us to implement when and if we do need them.

Benjamin S. Rogers
Web Developer, c4.net
voice: (508) 240-0051
fax: (508) 240-0057





~~~~~~~~~~~~~ Paid Sponsorship ~~~~~~~~~~~~~
Get Your Own Dedicated Win2K Server!  Instant Activation for $99/month w/Free Setup 
from SoloServer  PIII600 / 128 MB RAM / 20 GB HD / 24/7/365 Tech Support  Visit 
SoloServer, https://secure.irides.com/clientsetup.cfm.

Archives: http://www.mail-archive.com/[email protected]/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists

Reply via email to