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
