Hi Barry,
the "... common head/footers, common nav ... but changing "guts""
comment:
- most of that stuff (repeated layout) is handled via the fbx_layouts
mechanism. If you have lots of examples of code that looks like this:
<cfcase value="yourfuseactionname">
<cfinclude template="dsp_header.cfm">
<cfinclude template="dsp_body.cfm">
<cfinclude template="dsp_footer.cfm">
</cfcase>
then this app probably *isn't* using this mechanism. One possible reason
is that this app used to be plain old Fusebox and was "uphacked" to fb3.
As for "cascading fbx_switch and fbx_settings":
Only the fbx_settings "cascade". Only one fbx_switch will normally be
run (the one in the "target circuit" = the circuit housing your target
fuseaction).
Cascading fbx_settings helps with the pain of having to run common code
for all the fuseactions in a given circuit or circuit tree without
having to copy and paste code like <cfinclude
template="act_forcelogin.cfm"> in each and every fuseaction of a
circuit. It also lets your app inherit variables from one circuit into
its descendent circuits, whilst still giving you the chance to override
them if you need to.
"AJAX" - very doable. My suggestion is to create a special circuit
("remoting" or some such) and put all your AJAX end points in there (if
you don't have that many - otherwise it will get a little crowded in
there). Don't use any layout, just query and then return as JSON or XML
or whatever. If you've got loads of end points, then you should make a
whole tree of circuits to keep things neat and tidy. Think of it as a
separate interface to your model that returns something other than
complete pages.
"Self posting forms" - yucky. Why not have a "process_form" fuseaction
that cfmodules your "display_form" fuseaction on success?
Finally, the big question: if you're going to have to re-write major
parts of this app anyways, why not take the opportunity to switch to a
framework you're more comfortable or familiar with, or at least upgrade
to FB5.x? Not that there's anything inherently wrong with FB3, but why
invest time and effort in getting to grips with an obsolete framework?
/t
>-----Original Message-----
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED] On Behalf Of Barry Beattie
>Sent: Wednesday, October 25, 2006 4:58 PM
>To: [email protected]
>Subject: [CFCDEV] fundamental question about Fusebox
>
>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:
>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]
>
>
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]
