We've begun using subfusebox techniques, but I've taken what Hal initially
wrote and moved it a bit further along as I did not think it was complete
enough.
Subfuses theoretically should be able to plug into an application at any
level with the fusebox hierarchy. To this effect your app_locals.cfm becomes
vital. All subfuses control dynamic content only. NOT header/footers. These
are still controlled by the top level fusebox.
sub fuses also break the application.cfm check to see if an index.cfm is
being called. Also the directory location of a sub fusebox is not relevant.
It is also assumed that a fuse box application will only ever run ONE fuse
logic.
A typical app_locals.cfm is :
<!--- Include global variables/settings --->
<cfinclude template="#request.cfroot#/app_globals.cfm">
<!--- Default fuseaction for this circuit application --->
<cfparam name="attributes.fuseaction" default="ShowMain">
<!--- If a user somehow hacks into a lower level fusebox, then the
request.CallerFuseaction is not defined. The user should be redirected to
the main fusebox index.cfm --->
<cfif NOT ISDEFINED ("request.CallerFuseAction")>
<cflocation url="#request.cfroot#/index.cfm" addtoken="No">
</cfif>
<!--- Application Constants --->
<cfset request.CallerFuseAction = request.CallerFuseAction &"ORA.">
<cfset request.approot = "/oracle_maintenance">
Please note that all includes within the index.cfm (and all other files that
use includes within the sub fusebox) use request.approot
Mappings help, but are easily worked with if not available via the use of ./
../
I'm not saying this is perfect but this works.
your subfusebox index.cfm contains this:
<CFINCLUDE TEMPLATE="app_locals.cfm">
<CFSWITCH EXPRESSION="#GetToken(attributes.fuseaction,1,'.')#">
<cfcase value="ShowMain">
<cfoutput><p>Welcome to the main Admin application. You are
currently working on the <b>#request.MainDSN#</b> Database.</p></cfoutput>
</cfcase>
<!--- USER UPDATE FUSEACTIONS BEGIN --->
<cfcase value="userPreferences">
<cfset rfa.userPreferencesUpdate= #request.CallerFuseAction#
&"userUpdate">
<cfinclude
template="#request.approot#/dsp_user_profile_edit.cfm">
</cfcase>
<cfcase value="userUpdate">
<cfset rfa.success = #request.CallerFuseAction#
&"userUpdateSuccess">
<cfset RFA.fail=#request.CallerFuseAction# & "ActionFailed">
<cfinclude
template="#request.approot#/act_user_profile_update.cfm">
</cfcase>
<cfcase value="userUpdateSuccess">
<cfinclude
template="#request.approot#/dsp_user_profile_update_success.cfm">
</cfcase>
<cfcase value="userUpdateFail">
<cfset rfa.userPreferencesUpdate= #request.CallerFuseAction#
&"userUpdate">
<cfset RFA.fail=#request.CallerFuseAction# & "ActionFailed">
<cfinclude
template="#request.approot#/act_user_profile_update_fail.cfm">
</cfcase>
<!--- USER UPDATE FUSEACTIONS END --->
etc....
In your 'root' fusebox index.cfm you'd have the following...
<CFSETTING ENABLECFOUTPUTONLY="Yes">
<CFINCLUDE TEMPLATE="app_locals.cfm">
<!--- Return FuseAction structure --->
<CFSET RFA = STRUCTNEW()>
<CF_BODYCONTENT>
<CFSWITCH EXPRESSION="#GetToken(attributes.fuseaction,1,'.')#">
<!--- Oracle Management SubFuse --->
<cfcase value="ORA">
<cfset attributes.fuseaction= LISTREST("#attributes.fuseaction#",
'.')>
<cfinclude template="oracle_maintenance/index.cfm">
</cfcase>
<cfcase value="ShowMain">
<cfoutput><p>Welcome to the main application.<p><a
href="#request.cfroot#/index.cfm/fuseaction/ORA.ShowMain.cfm">Test Oracle
App</a></cfoutput>
</cfcase>
etc....
Your main app_locals would contain
<!--- Include global variables/settings --->
<cfinclude template="#request.cfroot#/app_globals.cfm">
<!--- Default fuseaction for this circuit application --->
<cfparam name="attributes.fuseaction" default="ShowMain">
<!--- As this is the top fusebox, the CallerFuseAction is set to "" --->
<cfset request.CallerFuseAction = "">
<!--- Default title text (in HTML <title> tag). It can be changed in URL
variable "titleText"
on inside <cfcase> sentences in index.cfm (i.e. in display handler
files) and it will
be included in header file. --->
<cfparam name="attributes.titleText" default="Metadata Maintenance">
The important thing to note is that request.CallerFuseAction is always added
to as you go through each sub_fusebox and that each parent fusebox has to
only know about it's child fuseboxes. Request.approot is redefined in each
sub fusbox app_local.cfm until the 'execute' SF is reached. This then uses
the app_root defined for itself.
Also note that the attributes.fuseaction has each 'subfusebox' identifier
chopped off as it is passed from parent fusebox to child fusebox.
I'm not saying this is perfect, but it works extremely well and enables us
to create functionality that 'plugs' into applications very very quickly. It
does require a well structured header/footer logic in place for the whole
application, but this is quite easy once rules have been established (ie.
what happens with a popup, frames etc..)
Have fun digesting the above....
Adam Reynolds
ColdFusion Consultant
H.J. Heinz
Tel.: +44 (0) 20 8756 5170
Mob.: +44 (0) 7973 386620
> ----------
> From: BOROVOY Noam[SMTP:[EMAIL PROTECTED]]
> Sent: 09 August 2000 16:28
> To: Fusebox List
> Subject: RE: sub-fuse
>
> There was a thread about nested fuseboxes (around 24 July).
> Basically the fuseaction contains a chain of actions e.g.
> fuseaction=BookStore.Cart.AddItem
> And all links point to the top level fusebox which then parses through the
> action handing it down to the correct fusebox which does the same till it
> reaches the last fusebox.
> All of the ones on the way may do some processing and/or displaying.
>
> This really should be formalised and posted onto the fusebox.org site
> under
> advanced techniques.
>
> HTH,
> Noam
>
>
>
> ----------
> From: Brad Roberts [SMTP:[EMAIL PROTECTED]]
> Sent: Wednesday, 09 August 2000 17:14
> To: Fusebox List
> Subject: sub-fuse
>
> Anyone have more ideas on sub-fuseboxes? I'm in the middle of
> trying to
> figure out the best way. It looks like using mappings is it, but I
> don't
> think my host is going to set up a mapping (or two) for every site I
> create.
> Any suggestions? Someone mentioned Hal's way, where can I find
> that?
>
> Thanks,
>
> Brad
>
>
> --------------------------------------------------------------------------
> --
> --
> To Unsubscribe visit
> http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/fusebox or
> send a message to [EMAIL PROTECTED] with 'unsubscribe' in
> the body.
> --------------------------------------------------------------------------
> ----
> To Unsubscribe visit
> http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/fusebox or
> send a message to [EMAIL PROTECTED] with 'unsubscribe' in
> the body.
>
**********************************************************************
This email and any attachments are confidential and solely
for the use of the intended recipient. They may contain
material protected by legal professional or other privilege.
If you are not the intended recipient or the person responsible
for delivering to the intended recipient, you are not authorised
to and must not disclose, copy, distribute or retain this email
or its attachments. Although this email and its attachments
are believed to be free of any virus or other defect, it is the
responsibility of the recipient to ensure that they are virus free
and no responsibility is accepted by the company for any
loss or damage arising from receipt or use thereof.
**********************************************************************
------------------------------------------------------------------------------
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/fusebox or send a
message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
