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
