I quite like the idea of just having a single file that is responsible for
setting up all the variables/structures required to run the application - it
keeps it all v simple with all the essential variables centrally located
rather than being distributed throughout various files. For me less files to
maintain is better.
Luke
-----Original Message-----
From: Adam Reynolds [mailto:[EMAIL PROTECTED]]
Sent: 17 May 2001 12:30
To: Fusebox
Subject: RE: RIGID STANDARDISATION IN EXTENDED FUSEBOX
I've expanded the Circuits.cfm idea. The main fusebox has to include so I
now include something called sysGlobals.cfm which sets up all of the
system level variables that I need. This effectively is the app_model.cfm
(if you use this).
Like I said, this is where standards come in. For example, all
request.site variables are set in the sysGlobals.cfm, (as well as the
request structures page and security).
Adam
-----Original Message-----
From: Jeff Peters [SMTP:[EMAIL PROTECTED]]
Sent: 17 May 2001 11:47
To: Fusebox
Subject: RE: RIGID STANDARDISATION IN EXTENDED FUSEBOX
Your instincts are accurate, Luke. myGlobals.cfm shouldn't be duplicated
throughout the site. Rather, each circuit's file should set variables
particular to that circuit. Variables set by the parent circuit will be
inherited by all children. Each circuit has its own myGlobals.cfm to
allow it
to function either as a standalone module or as a circuit in a different
application, should you decide to reuse the circuit at some point.
- Jeff
On 17 May 2001, at 11:00, Luke Bartholomew wrote:
> 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
