I have a quick idea from Gabe's app_model.cfm idea to improve upon the
idea of "plug & play" fusebox apps....

As a community we could keep a live list of what the "standard"
app_model.cfm file contains.  Things like: #request.ds.maindsn#,
#request.site.urltoken# etc.  I'm thinking we should have an application
on Fusebox.org that allows people to vote on whether a variable should
be in the "standard" app_model.cfm file.  Regardless you could still add
your own variable names to the app_model file.  The reason for the
standard is so that "plug & play" fusebox apps will work together.

Anyway.... my new idea is that each circuit application would have it's
own app_model.cfm file.  Some variables would be inherited from parent
applications while other variables would not be.  By using <cfparam>
with default values in our app_model.cfm file any app_model.cfm file
that is called from cfmodule would inherit the calling templates
app_model values.... along with set any new values that do not exist
that are required for that circuit app.

Make sense?

See if you can follow the logic of this tree:

http://www.blah.com/app1/index.cfm?fuseaction=somefuseaction            (written
by Steve)
  |
  --------<cfinclude template="app_model.cfm">
                |
                --------<cfparam name="request.ds.maindsn" default="stevesdsn"> 
  |
  --------<cfmodule template="app2/index.cfm"                           (written by 
hal)
                .....>  
                |
                --------<cfinclude template="app2/app_model.cfm">       
                                |
                                --------<cfparam name="request.ds.maindsn" 
default="halsdsn"> 


Here's the cool part.... when Hal is working on the application he can
maintain his own database on his development server and name his
datasource "halsdsn".  As long as our database schemas match up when I
call his application in my application my value of #request.ds.maindsn#
("stevesdsn") will override his value set in app_model.cfm.  This would
work for another couple dozen types of common variables.  Then any
variable that is not in the Fusebox "standard" list could be called
without a default value meaning the parent application needs to set it. 
That part is a little hairy, we'll have to discuss how it works.

By doing this he can do his work in his own environment and I can work
in my own environment and bringing the two apps together will be that
much easier.

Thoughts?

Steve Nelson
http://www.SecretAgents.com
Tools for Fusebox Developers
(804) 825-6093

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        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

Reply via email to