On 10/25/06, Barry Beattie <[EMAIL PROTECTED]> wrote:
hi all
please forgive this basic-level request for an overview about Fusebox,
but I'm just trying to get a better understanding on the big question
"why".
I really miss having the controllers I'm used to and sometimes it
feels like FB is getting in the way or making things more complicated
than it needs to be. that and being annoyed by the lack of abstraction
like variables, queries, etc, created in one cfinclude but referred to
in another within the same switch.
But this was a huge leap forward in 2001. Remember, FB3 was designed
to work with CF 4.52. It was born in an age of no CFCs or even UDFs.
Fusebox brought order to the land of endless nested includes.
Fusebox 2 was basically just a bunch of loosely defined conventions, a
mess by today's standards. But it was a step forward at a time when
most CFers were new to programming and CF apps tended to be very
disorganized and inconsistent.
Fusebox 3 was the first Fusebox "framework." In fact, it was the first
framework for ColdFusion that gained critical mass. One of the design
goals of FB3 was just to get people understand and accept the concept
of a framework -- a standard, shared library on which application code
is built.
FB3 was supposed to ameliorate the weird scoping issues inherent to CF
with some simple conventions. The fusebox API -- a structure, the most
powerful tool in the CF 4.52 toolbox -- was used to communicate with
the framework. The attributes scope was used for communication between
fuses. Unscoped (variables-scoped) variables were considered local to
the fuse.
We had no way to enforce those rules, so we kept them as simple as
possible, in the hope that smart programmers would follow them without
trouble or objection.
I had hoped the next version would improve on FB3 by incorporating
CF5/MX features. For example, instead of directly writing to the
Fusebox structure, we would provide accessor methods. We might have
used functions instead of templates for fuses. Perhaps fuseactions
would become public functions and circuits would become CFCs. Nested
circuits could become decorated CFCs.
it may just be this old version or how it's used, but FB feels like
it's suited to easily build only one type of app - common
head/footers, common nav, menues, etc, but with changing "guts".
Yes, I think that pretty much sums up what made FB3 useful, beyond
taming the chaos of framework-less code. The other big benefit of FB3,
calling a circuit as a custom tag, was obviated by the introduction of
CFCs. (Someone created a custom tag, cf_call, so we could call FB3
fuseactions and have them return values as if they were functions. The
tag ended up looking a lot like today's cfinvoke. Or vice versa. ;-))
These days, I still have sites that were written in FB3 a long time
ago. I don't have time to redo them all for the sake of changing
frameworks. But every time I touch circuit-as-a-custom-tag code, I
weigh the benefits of converting that circuit to a CFC.
Lately I've been using Reactor behind FB3 code. So it's FB3 front end
+ plain old CFC service layer + Reactor.
The use of Remoting, Ajax calls and self-posting forms are do-able but
not quite as straight-foward to what I'm used to.
That's because FB3 was created for Web 1.0 ;-) I have my
HTTPXMLRequest calls bypass Fusebox. They go to plain old CFM
templates that in turn call the service layer.
is this a fair summary or have I got a dog of an example to be underwhelmed by?
Yes, and yes. It sounds like you have a dog. FB3 allows a skilled
programmer to produce elegant code quickly. But a skilled programmer
who's used to modern CFC-based frameworks may struggle with it. And
these days there's no good reason to make FB3 the centerpiece of your
app. It should be relegated to the HTML front end.
Sure this is FB3 and FB5.1 is now out there, but as far as the core
features of cascading fbx_switch and fbx_settings files, what pain do
these actually solve?
1. Duplicate code.
2. Poor structure (or no structure at all).
3. Inconsistencies between applications / programmers.
4. Complex rules for building HTML pages.
Today, we don't think about those pains nearly as much as we used to.
We don't think about #4 because it's not sexy -- however, I still find
John QvTs nested layouts model indispensable. #1 is addressed by UDFs
and CFCs. #2 and #3 are covered by the plethora of frameworks we have
today. But it all started with Fusebox 3.
--
Patrick McElhaney
704.560.9117
You are subscribed to cfcdev. To unsubscribe, please follow the instructions at
http://www.cfczone.org/listserv.cfm
CFCDev is supported by:
Katapult Media, Inc.
We are cool code geeks looking for fun projects to rock!
www.katapultmedia.com
An archive of the CFCDev list is available at
www.mail-archive.com/[email protected]
