Well, if you like XFB but don't want to change from regular FB try this.
First, only the parent application will have an app_globals.cfm and Second
all applications have their own app_locals.cfm
app_globals.cfm (stripped to the bare minimums)
--------------------------------------------------
<cfif not isDefined('attributes.fuseaction')>
<cf_formurl2attributes>
</cfif>
<cfapplication name="zzz" sessionmanagement="Yes" clientmanagement="Yes">
<cfinclude template="app_model.cfm">
<cfinclude template="app_server.cfm">
<cfset request.page.headerfile = "header.cfm">
<cfset request.page.footerfile = "footer.cfm">
----------------------------------------------------------------
app_locals.cfm
------------------------------------------
<cftry>
<cfinclude template="app_globals.cfm">
<cfcatch type="MissingInclude">
</cfcatch>
</cftry>
<!--- your local settings here --->
----------------------------------------------------------------
index.cfm
-----------------------------------------------
<cfinclude template="app_locals.cfm">
<cfparam name="attributes.fuseaction" default="main">
<cfif not isdefined('request.circuits')>
<cftry>
<cfinclude template="app_circuits.cfm">
<cfcatch type="MissingInclude">
Error - I am unable to load my circuits registry.
<cfabort>
</cfcatch>
</cftry>
<cfelse>
<cfif listlen(attributes.fuseaction,'.') gte 2>
<cfset attributes.fuseaction = listdeleteat(attributes.fuseaction,1,'.')>
</cfif>
</cfif>
<cfif not listlen(attributes.fuseaction,'.') gte 2>
<cf_bodycontent>
<cfswitch expression = "#attributes.fuseaction#">
<cfcase value="main">cough</cfcase>
<cfdefaultcase><cfoutput>Error - An Invalid Fuseaction Was
Called.</cfoutput></cfdefaultcase>
</cfswitch>
</cf_bodycontent>
<cfelse>
<cftry>
<cfset attributes.fuseaction =
request.circuits[listfirst(attributes.fuseaction,'.')]&'.'&listlast(attribut
es.fuseaction,'.')>
<cfcatch>
I could not resolve the circuit application prefix sent to me.
<cfabort>
</cfcatch>
</cftry>
<cfinclude template="#ListFirst(attributes.fuseaction,'.')#/index.cfm">
</cfif>
----------------------------------------------------------------------------
-----------------------------
app_circuits.cfm
----------------------------------------------------------------------
<!--- My Circuit's Registry. --->
<cfset request.Circuits = StructNew()>
<cfset request.Circuits.bob = "circuit2">
<cfset request.Circuits.john = "circuit2/circuit3">
----------------------------------------------------------------------------
------------------------------
This little example has no function but does work. When I first eval'd XFB
(why call it that? Its all Fusebox) I came up with these little changes,
that made more sense to me.
Granted once I was done I didn't like the navigational model of the whole
XFB thing, but I do appreciate why someone would need to use it, especially
if they're a good sized development house, or they farm out most of their
work, and can't expect the developers to know how far down their section is
going to be placed within the final application.
Fred
----- Original Message -----
From: "Luke Bartholomew" <[EMAIL PROTECTED]>
To: "Fusebox" <[EMAIL PROTECTED]>
Sent: Thursday, May 17, 2001 6:00 AM
Subject: RE: RIGID STANDARDISATION IN EXTENDED FUSEBOX
> Having picked up the Fusebox methodology about 5 months ago, I am now
moving
> attempting to learn the XFB specification to develop my apps.
>
> Really I have two questions.
>
> XFB appears to be v useable, but there is only one grey area which I am
not
> so sure about...and that is that MyGlobals.cfm (I still use the
> app_globals.cfm naming convention).
>
> Working with the XFB spec I found that this file must be duplicated
> throughout the site to ensure that the site wide variables are set up e.g.
> mainDSN, headerfile, footerfile, webroot etc. Currently, I am developing a
> fairly large application and I don't really see any advantage of this
method
> other than allowing you to create a modular design. In fact, it means that
> when one of these variables changes I have to update all the other
> MyGlobals.cfm files. In the original Fusebox spec the app_globals.cfm only
> fired once and it was always situated at the root of the application.
> Forgive me if I have missed something simple, but this does seem more
> manageable. Why can you not have one MyGlobals.cfm file and the location
to
> this file is set up in the circuits.cfm file (obviously being the root of
> the application) and then use app_locals.cfm (or MyLocals.cfm) for all the
> variables relating to any specific fusebox. Then you could ensure that it
> would only load once. Please put me straight if I am totally off track.
>
> The second question relates to using structures to hold the necessary
> request.security, mappings, request.global etc variables. Are these
created
> in the the MyGlobals.cfm template, and are therefore available to all
> fuseboxes?
>
> Regards
>
> Luke B.
>
>
>
> -----Original Message-----
> From: Ken Beard [mailto:[EMAIL PROTECTED]]
> Sent: 16 May 2001 17:49
> To: Fusebox
> Subject: Re: RIGID STANDARDISATION IN EXTENDED FUSEBOX
>
>
> 2cents:
>
> I use
> request.page: layout stuff, headers, stylesheet filename, etc
> request.security.groups
> request.security.levels
> request.path: path variables, and here I use 3 prefixes cf_ dir_ and url_
> for cf mappings, physical paths and a url path
> also i include request.path.domain and request.path.cookiedomain
> within this structure
> request.global: datasrc, datasrc_pw, datasrc_un, other misc app-specific
> vars
>
>
> i've probably asked b4 but i forget.. is there a home for the app_model
> discussion/standard on the web somewhere? I want to see what's current.
>
> At 09:59 AM 5/16/01 +0100, you wrote:
> >Extended Fusebox is great, but does anybody believe a set of 'structure'
> >standards are necessary?
> >
> >For example we use a sysGlobals.cfm that is included by the main fusebox.
> >This creates a set of structures that we use to manage site wide issues.
> >
> >The sturctures are:
> >request.page :
> >This manages page issues. We currently assume circuit apps deliver body
> >content only and that the main fusebox uses <cf_bodycontent> with
> >app_layout.cfm to wrap up the content. This structure enables each
circuit
> >to direct the output to be appropriate for the circuit. It allows you to
> >set page title, metatags etc after the generation of the core content of
> >the page. It also deals with the page mode, which the dsp_header/footer
> >files uses to determine what to put at the top and bottom of a page.
> >request.site :
> >Used to hold directory paths (for upload of files), database name, type,
> >testmode etc.
> >request.security :
> >Holds security information. I've found this useful when using the
> >member/group login (as per the fusbox book) on a site to identify key
> >groups (i.e. siteadmin). Each circuit can 'supplement' the groups with
its
> >set of key group(s). It also holds the file paths for app_login,
> >app_secure, app_logout from the root of the application.
> >
> >What I'm trying to get at is that if a circuit conforms to the 'Fusebox
> >Extended Circuit Standard' then integrating other peoples circuits into
> >your own will be easier.
> >
> >I'm not saying you should not go your own way, but that if we can come up
> >with a standard for Extended fuseboxes then it should allow easier
> >interchange of components.
> >
> >
> >Best Regards,
> >
> >Adam Reynolds
> >ColdFusion Web Developer
> >ISMG Development, Unilever
> >London
> >
> >( +44 20 7822 5450 (ext 5450)
> >m: +44 7973 386620
> >* [EMAIL PROTECTED]
> >
> >
> >
> >
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Structure your ColdFusion code with Fusebox. Get the official book at
http://www.fusionauthority.com/bkinfo.cfm
Archives: http://www.mail-archive.com/[email protected]/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
