Hmm well there isn't really a whole point to fusebox per say. The point
really is to have a architecture methodology. Fusebox attempts to
standardize a methodology. This standard however doesn't work for everyone.
For instance, if you work at Figleaf I would imagine when you walk in the
door you get the "This is our methodology" handbook. That would be the
standard for project architecture in that company. Now the stuff that comes
out of Figleaf is just beyond compare, so I would say that whatever thier
methods are, they most likely don't need or want a new one. But what does
someone do if they are subcontracting work or just starting a development
company and have no methodology? Well, you are going to have to develop
some architecture rules that everyone adhears to. Fusebox attempts to offer
a solution to such by standardizing a methodology.
For me personally fusebox works quite well. I am a project magnet. I go
weeks without answering my phone because I just cannot handle the load.
Well quite honestly, I have been wrapping up two major projects so I haven't
been answering the phone in a few months. However when I am, the work just
streams in. What fusebox allows me to do is subcontract that work very
easily. I can subcontract work to people I have never met or worked with,
by simply delivering them a scope document. That the work is done in
fusebox, there are no misunderstandings as to what I will accept as
architecure and each developer can build thier module or piece of the
project independently and when they are finished those modules can just be
"plugged in" to each other. And so far as "most don't use fusebox" is
concerned, I have never had a problem finding good developers that can
program using fusebox's standards.
Fusebox is far from complex. It makes programs easy to read by other
developers that use the same methodology because you do not need to follow
spaghetti-like threads to figure out what the programmer before you was
doing or how they did it. You simply look at the main index page and see
what fuseactions are attributed to which modules. Each module has its own
index page which directs traffic in its subapplication. So, if you are
fixing or modifying a message board you can easily figure out which
templates are associated and what function those templates provide by simply
looking at the index page. I find when I am hired to modify or fix
pre-existing applications few clients have documentation for those
applications and by and large, those applications are not well commented.
For the client this means that a great deal of billable time is spent just
figuring out how the application functions. Recently I was hired to modify
a website built in fusebox. I have no idea who the previous developer was
and the client's dog ate the documentation. However, it took less than an
hour to figure out the application and less than a day to re-document it.
Wherein the application was in its self complex the modifications were
easily implemented as they were simply plugged in rather than redesigning
spaghetti like business logic.
Now, if you are not used to programming in fusebox, these principles may not
be as appearant to you or to someone who does not use the methodology.
Conversely, you may have a pre-existing methodology that just rocks and to
you and your team it is very easily implemented, however that I do not use
your methodology simple principles in your design may not be as appearant to
me as I am not familiar with it.
I am not sure what 10-15% extra work you are talking about, I find fusebox
actually saves me time. Fusebox as a methodology leans heavily on code or
module reuse. With the exception maybe of UI, each new project is made up
of pre-existing modules that are just plugged in. Its kind of like building
an an EJB which acts as your standard shopping cart. Everytime you have a
client that needs a shopping cart you don't rebuild the thing over and over,
you just plug yer EJB in. Fusebox is pretty much the same principle. Most
of my small to mid-size clients are built by cutting and pasting modules
then making a main index page which directs traffic.
A standardized naming convention is but a fraction of application
architecture. Fusebox has a naming convention as well, but the naming
convention is arbitrary, the fusebox guys could have named their act_
templates cgi_ . So this gives you an idea what the template does, but says
nothing of the over all architecture. Again, fusebox is A methodology. It
is THE methodology that works for me. If you have a methodology that works
for you and your company, chances are, like Figleaf you do not need to adopt
a new one. However, if you or your company presently do not have a
application architecture methodology or are looking for one that you can
easily subcontract work with I highly recommend Fusebox.
Sean Renet
----- Original Message -----
From: "war ape" <[EMAIL PROTECTED]>
To: "CF-Talk" <[EMAIL PROTECTED]>
Sent: Wednesday, December 20, 2000 6:22 AM
Subject: Fusebox
>
> Whats the whole point of Fusebox?
> I don't see how it makes an application any less proprietary
> i i know it helps modularize an application for reuse, but how does it
help
> make the application more understandable to other programmers?
> Most don't use fusebox, so right there its been made harder
> also i think it adds a dense layer of complexity to an application,
> basically adding another 10-15% work to the appllication.
> I don't see that it does much that could not be achieved with a
standardized
> naming convention.
> Sorry if i seem the philistine, but my mantra has always been simplicity,
> simplicity is what makes an application more accessible to later
programmers
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Structure your ColdFusion code with Fusebox. Get the official book at
http://www.fusionauthority.com/bkinfo.cfm
Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
