Lee
Yeah - I'm beginning to see the logic there now, and it does seem to be
almost too good to be true. Just to confirm - each circuit should have the
following files:
app_globals.cfm
app_circuits.cfm
app_layout.cfm (I am using the bodycontent.cfm custom tag - brilliant)
Application.cfm (to prevent users from viewing files other than the
index.cfm)
Index.cfm
scripts.js (local javascript functions)
styles.css (local stylesheet)
blocks/dsp_header.cfm
blocks/dsp_footer.cfm
Queries/qry_queryname.cfm (contains all query files)
Actions/act_actionname.cfm (contains all action files)
display/dsp_displayname.cfm (contains all display files)
And I guess that the circuit can inherit the parent stylesheet or
header/footer files or include it's own according to settings in the
app_globals.cfm.
Is this about right? :->
Ta.
Luke B.
-----Original Message-----
From: lee borkman [mailto:[EMAIL PROTECTED]]
Sent: 18 May 2001 14:27
To: Fusebox
Subject: RE: "duplicating myGlobals" (RE: RIGID STANDARDISATION IN
EXTENDE D FUSEBOX)
Hi Luke,
XFB doesn't really demand that you "duplicate" your myGlobals files. All it
requires is that each circuit comes equipped with a myGlobals that
defines/inherits/overrides everything needed in order for the circuit to run
on its own.
That means that many of your myGlobals files will be very similar, of
course, but you don't need to change every one of them whenever you want to
make a site-wide change. If you want to change the main datasource
site-wide, then you just change it in the top-level myGlobals, and let all
the lower-level circuits inherit the new value (use CFPARAM in your lower
circuits to allow inheritance).
In other words, if a change is to be made to every app from CircuitX
downwards, then you just change the value in CiruictX's myGlobals. You
don't need to change it anywhere else, because all of the sub-circuits will
inherit the change.
That is much of XFB's great beauty. You can make site-wide changes by
changing the value in a single location, because XFB provides inheritance.
Hal likes to say that Java or CFObjects is where we should look if we want
OO stuff like inheritance, but I think he's being a little sly there. XFB
to me is nothing more nor less than a means of providing FuseBox with
inheritance and overriding of properties (ie variables), though not of
methods (ie fuses and fuseactions).
So develop your circuit app stand-alone, with its own myGlobals defining
everything that is needed. Then plug it in, and now you only need to change
the home app's myGlobals and let all the circuit apps down below inherit or
override as they see fit. Don't go deleting all of the lower-level
myGlobals, because they control what is inherited and what is overridden.
They also set values which only have meaning within a particular circuit.
Of course, these values can then be inherited by circuits even further down
;-)
So I guess I'm saying that the problem you perceive isn't really there at
all. You don't need or want to duplicate anything (except in your
circuits.cfm, which is pretty trivial). Each level's myGlobals simply
defines/inherits/overrides all of the things that are global from that point
downwards.
You get a real bonus for testing. You mention datasources. XFB will let
your circuit use a test datasource when the app is called stand-alone, but
use the production datasource when called as part of the home app. I don't
know that would really be a good idea, but XFB would give you that power.
That's because the myGlobals are NOT duplicates. They can all set entirely
DIFFERENT values. Which values actually get used depends on which circuit
is called as the home app. Lots of power, lots of flexibility, MINIMUM
duplication. Bingo!
So hey, I guess I'm an XFB convert. Hal has won me. My team is now
building and testing apps, and plugging them into the big-mother home app so
fast that I fell a little faint.
Best of luck,
Lee.
>From: Luke Bartholomew <[EMAIL PROTECTED]>
>Date: Fri, 18 May 2001 12:34:54 +0100
>
>I understand the principle that each circuit should have everything that it
>needs to run as a stand-alone app which is a great goal to aim towards, but
>the fact is that in XFB is doesn't completely succeed - as you still need
>to
>copy and re-write certain files.
>
>For example, the app_circuits.cfm will no longer be required and the new
>circuit will have to be defined in the app_circuits.cfm file of the parent
>application. There is also a high probability that you will need to edit
>many of your request.variables in the app_globals.cfm file, such as
>request.site.cfroot etc.
>
>The concept that I have been messing around with the last couple of days it
>that there is a single app_model.cfm for each circuit which holds all the
>site wide variables (as already discussed previously in this thread), and
>this app_model.cfm file only fires when the circuit is the parent app. Then
>each circuit also has it's own app_globals.cfm (as XFB spec states) which
>over-rides any variables set in the app_model.cfm file e.g.
>request.site.description or sets up a new stylesheet or javascript file in
>the dsp_header.cfm.
>
>Although I can still see problems with the solution outlined above, I am
>still playing with this and believe that it may eventually provide me with
>a
>cleaner solution to my problem, which is that with approximately 30
>circuits
>in my application, it is just not manageable to be forced to duplicate the
>app_globals.cfm file in every circuit
>app.
>
>For example, when I move from development to testing phase, I will need to
>update every reference to request.site.cfroot (and any other such
>variables)
>in all 30 of the app_globals.cfm templates - headache. And then the
>request.site.mainDSN variable needs to be changed a couple of days later -
>it just doesn't seem good.
>
>There must be a way of achieving the same goal (i.e. complete modularity
>and
>ability to run applications stand-alone) without encountering this
>potential
>problem).
>
>I guess that it really depends upon which trade-offs you find most
>manageable. Are there any more thoughts on this subject? :-)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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
