Sounds like a winner to me, Steve. Many folks would benefit from a model that
essentially says, "if you need an application variable to store a piece of
information like X, here's a standard name to use". Of course, you could pick
and choose, only using those variables you need for your app.
This could cause development of some pretty cool ready-to-use circuits.
- Jeff
On 22 Dec 2000, at 12:15, Steve Nelson wrote:
> 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
