As far as I understand it, the idea of sub-fuseboxes (SFs from now on) is to
encapsulate functionality as part of a parent fusebox. Your decision
structure should always pass through the parent fusebox (PF from now on). As
a SF will not know how many levels of PFs there are, it must use:
<cfset request.CallerFuseAction = request.CallerFuseAction &"TLA.">
<cfset request.approot = request.cfroot & "/../../../sf_directory">
I understand it to be the case that no matter how many decision structures
(TLA.TLA2.TLA.fuseaction) are navigated that only the logic for one SF case
is finally ever executed and that all output is presented to the user by the
top level fusebox in the fusebox hirearchy.
So in theory request.CallerFuseAction will grow as each SF is navigated, and
request.approot will be set again and again until it actually is required
for the execution of the final SF logic.
This enables nestes sub fuseboxes, with each SF only knowing about its Logic
and about it's calls to other child SFs.
The top-level Fusebox handles general display, security, and navigation into
SFs it calls.
Changes to the top level index are:
<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>
AND to app_locals:
<cfset request.CallerFuseAction = "">
Soooo this enables one of my developers to go implement functionality (like
an Oracle User Manager) and then simply plug it into a currently live system
with one minor addition to the parent fsuebox within which it will sit plus
a little bit of manipulation of the dsp_header.cfm (or wherever you wish to
put navigation requirements).
It does break request.cfroot in the specific SF as it uses request.approot
for locating it's files but that is a minor issue. All fuseactions are still
passed via #request.cfroot#/index.cfm
Please note that we have a global security based on the
http://www.teamallaire.com/newsletters/JulyNewsletter.cfm
which is extremely clean. This security is always managed within
app_globals.cfm
Right, hope that helps.
Adam Reynolds
ColdFusion Consultant
H.J. Heinz
Tel.: +44 (0) 20 8756 5170
Mob.: +44 (0) 7973 386620
> ----------
> From: Paul Johnston[SMTP:[EMAIL PROTECTED]]
> Sent: 02 August 2000 11:45
> To: '[EMAIL PROTECTED]'
> Subject: RE: Sub-Fuseboxes
>
> 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
>
>
**********************************************************************
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.
