I feel that this overcomplicates the issue of sub-fuseboxes. The use of
sub-fuseboxes must be simple, and not (IMHO) include putting bespoke code
anywhere. What I mean is that there should be a standard set for this
(anyone agree?) as soon as possible, so that code can easily be passed
between developers and be very easy to read and debug (because that's the
whole point of fusebox) as well as being quick to develop.
Putting this code into the app_locals.cfm file really doesn't help that
much, because you are just setting a bunch of global variables (ie the path
to the sub-fusebox) whereas the app_locals.cfm is for local variables (hence
the name!). There also appears to be some output from your app_locals.cfm if
they hit the fusebox root. This doesn't make sense because then you are
taking away the code from the fusebox and putting it into a
non-fusebox-standard architecture. Anyone agree with this?
One thing I don't think this does very well, is follow a path to a
sub-fusebox. Imagine a case where you have a search fusebox, and you have
cds and books. Using your method (as I understand it), you may not have a
separate path for:
home.books.search
and
home.cds.search
Please correct me if I'm wrong (and I could be) because I may have
misunderstood your code.
I would like a discussion on sub-fusebox standards because it's beginning to
bug me!
Paul
> -----Original Message-----
> From: Reynolds, Adam [mailto:[EMAIL PROTECTED]]
> Sent: 02 August 2000 10:19
> To: '[EMAIL PROTECTED]'
> Subject: Sub-Fuseboxes
>
>
> I've begun using the following in my app_locals file for
> sub-fuseboxes:
> <!--- 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 = request.cfroot & "/oracle_maintenance">
> <!--- 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. --->
> <cfset attributes.titleText="Oracle User Maintenance">
>
> The index.cfm for the subfusebox then uses:
> <CFINCLUDE TEMPLATE="app_locals.cfm">
> <CFSWITCH EXPRESSION="#GetToken(attributes.fuseaction,1,'.')#">
>
> <cfcase value="ShowMain">
> <cfoutput><p>Welcome to the main Oracle application.
> <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>
>
> Please note the use of #request.approot# rather than
> #request.approot#.
> Sub-fusebox applications can then be easily be copied into current
> applications as a subdirectory. Has made life very very easy.
>
> Anybody else come up with an easy deployment procedure for
> sub fuse box
> structures into any fusebox hierachy?
> Adam Reynolds
> ColdFusion Consultant
> H.J. Heinz
> Tel.: +44 (0) 20 8756 5170
> Mob.: +44 (0) 7973 386620
> **********************************************************************
> 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.
------------------------------------------------------------------------------
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.
