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
