That's the way I'm playing it, but I am keeping system wide globals in a
seperate file to myGlobals as myGlobals deals with specific circuit issues.
I also think Circuits.cfm. I think you need a path stucture as well so
that the url to the root of each circuit is available. Useful when
developing content systems that allow you to upload to a specific
subdirectory of a circuit.
Maybe I'm thinking too deeply about this and as this is something that
would only ever be needed by specific circuits, it should simply be in the
myGlobals for the circuit.
Adam
-----Original Message-----
From: Luke Bartholomew [SMTP:[EMAIL PROTECTED]]
Sent: 17 May 2001 12:15
To: Fusebox
Subject: RE: RIGID STANDARDISATION IN EXTENDED FUSEBOX
So in answer to my second question, will the myGlobals.cfm file in the
parent circuit set up all the site dependent structures such as
request.security, request.mappings, request.globals etc, and then each
child
circuit has a myGlobals.cfm which will only contain variables relating to
that particular child circuit?
Thanks
Luke
-----Original Message-----
From: Jeff Peters [mailto:[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
