I think you got a dog of an app. Sadly, as FB was the only framework
available for quite a while, a lot of people mindlessly adopted it
with no real understanding of how it worked or how to use it
effectively. That's still the case, of course, but the CF community
as a whole has matured significantly since FB3's heyday.
FB is a very simple framework, much simpler than M-G or M-II. That's
both its biggest asset and one of it's drawbacks. It has some
advanced features (such as custom lexicons), but the core of it is
quite simple and hasn't really changed since the beginning.
Each fuseaction (CFCASE statement in your fbx_Switch.cfm in FB3's
case) is a request controller. As you'd expect, the controllers
delegate to the application backend and then hand off processing to
the view. Here's a couple simple examples from one of my FB3 apps:
<cfcase value="deleteGallery">
<cfset xfa.success = fusebox.targetcircuit & ".home" />
<cfset imageList = imageservice.deleteGallery(attributes.galleryID) />
<cfinclude template="act_success.cfm" />
</cfcase>
<cfcase value="quickStats">
<cfset series = "totalCount,capacity,toImport" />
<!--- most of the time just pull recent results, but periodically
refresh them --->
<cfif randRange(0, 10) EQ 0>
<cfset counts =
factory.getBean("countService").recordCounts(series) />
<cfelse>
<cfset counts =
factory.getBean("countService").getLastCounts(series) />
</cfif>
<cfinclude template="dsp_quickstats.cfm" />
</cfcase>
You can see the basic pattern in both fuseactions: set up the request
handler (define XFAs, use CFPARAM, etc), do some processing (calling
the service layer), render a view (a redirect in the first case (via
act_success.cfm), a dsp_ fuse in the latter).
act_success.cfm (in the deleteGallery fuseaction) is a reusable piece
of controller code that will forward to xfa.success, unless a request-
or session-level return fuseaction exists, in which case it'll forward
there.
Also of note is that the quickStats fuseaction is just a content block
that I use as part of the layout of various pages. That style of
multi-part page assembly is very possible with FB, including FB3. I
pretty much skip the use of nested layouts except for applying global
elements. Here's a helper function that is basically equivalent to
the DO action in FB4/5:
<cffunction name="do" returntype="void">
<cfargument name="fa" type="string" required="true" />
<cfargument name="variable" type="string" required="false" />
<cfset var oldfa = fusebox.fuseaction />
<cfset fusebox.fuseaction = fa />
<cfif structKeyExists(arguments, "variable")>
<cfsavecontent variable="#variable#">
<cfinclude
template="#fusebox.circuits[fusebox.thisCircuit]#/fbx_Switch.cfm"
/>
</cfsavecontent>
<cfelse>
<cfinclude
template="#fusebox.circuits[fusebox.thisCircuit]#/fbx_Switch.cfm"
/>
</cfif>
<cfset fusebox.fuseaction = oldfa />
</cffunction>
Drop that in your root fbx_Settings.cfm file and you can call
fuseactions within the same circuit recursively with a minimum of
fuss. If you want to do cross-circuit calls, it's easy to tweak.
Just keep in mind that it's not a complete call - fbx_Settings is not
called and layouts are not applied, only the fuseaction is executed.
Regarding the shared variables scope, it's not unlike the view state
from M-G, just less abstracted. It's simpler to work with, but at the
expense of a little bit of encapsulation. However, with how "thin"
your UI controller and view layers should be in a well architected
application, that's not much of an issue. The vast majority of your
coding should be inside your "backed", probably exposed as ColdSpring
managed services, and therefore the variables scope will be quite
barren.
Unlike M-G and M-II, FB doesn't force you to build apps in a certain
way. With M-G, you HAVE to use event broadcast to M-G specific
listeners to get anything done, and M-II has a similar paradigm. It's
easy to synthesize that with FB, but you don't have to. That's a
double edged sword, resulting in simple construction of advanced apps
by competent developers and the difficult construction of
spaghetti-logic apps by less competent developers.
cheers,
barneyb
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".
the last month or so has been my first real use of Fusebox. Sadly,
it's an FB3 app of a couple of years old that I'm
extending/maintaining. In it there's bugger-all business processes
abstracted into functions (just heaps of qry_, act_ and dsp_ files)
and what CFC's that have been added are full of display code (HTML/JS
for pete's sake! - someone before me obviously got the wrong idea with
CFC's...). Also, cardinal sins of having too much logic embedded
within the fbx_switch files makes it a bit of a challenge to
appreciate what Fusebox does (and 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. it just seems to make it harder to
get a good (quick) top-level grasp of each business process.
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". 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.
is this a fair summary or have I got a dog of an example to be underwhelmed by?
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?
any advice, opinons most welcome
thanx
You are subscribed to cfcdev. To unsubscribe, please follow the instructions at
http://www.cfczone.org/listserv.cfm
CFCDev is supported by:
--
Barney Boisvert
[EMAIL PROTECTED]
360.319.6145
http://www.barneyb.com/
Got Gmail? I have 100 invites.
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]
