Alrighty then. Steve, Nat, and Hal could break the big boss's overarching
design plan and have the highest of the three (Hal) write the stateslist
thing once, and they could all just "believe" that it exists, and not write
it themselves. Yeah sure, they could write it themselves and wrap it in a
cfif IsDefined (if it involves a DB call), but that's too much duplication
of code across multiple circuit apps for my tastes. My current project has
MANY such application wide variables, lists, etc. Heck, we even have a file
that gets included off of the app_globals called app_lists. Therefore,
requiring all the circuits that need the information in app_lists to
essentially copy-n-paste the contents of app_lists into each one's myGlobals
is far too redundant and prone to syncronization issues for my tastes.
Maybe I just don't believe you - would you really (REALLY) duplicate
potentially 100 lines of global variables-type code in every single
myGlobals (imagining that there are 30 apps), then attempt to update all of
them if the composition of the global variables needs to change?
Maybe I should just pay the $5k and figure it out in October...
Nat Papovich
ICQ 32676414
"If it was hard to write,"
says the Real Programmer,
"it should be hard to understand."
-----Original Message-----
From: Hal Helms [mailto:[EMAIL PROTECTED]]
Sent: Friday, October 06, 2000 3:43 AM
To: Fusebox
Subject: RE: Multiple app_globals includes?
The problem with cflocating from circuit to circuit, from my POV, is that
circuit app writers have to know too much about what's going on in other
circuits. That makes reuse of circuit's require lots of hand tooling and
that means we're back to having supercoders do more and more stuff because
only supercoders have the requisite knowledge to change *anything* on an
application that has no clear boundaries. (More of this rant -- and my
proposed solution -- at cf_underground...) Without things going back through
the home app, you don't really have nested fuseboxes as much as you have a
federation of fuseboxes. This is much harder to maintain as there's no
inheritance mechanism as there is with nested fuseboxes.
As to your more immediate concern, once Steve, Hal, and Nat got together
(and after the charges of public disorder were dismissed), they would see
that there is a big application (they had no idea, remember, that there WAS
a big application) that uses all their little apps. If someone noticed that,
remarkably, they all use stateslist, they could suggest to the Big Boss that
it would be more efficient if this were set in the home app's myGlobals?
Since the circuit apps would have this <cfparam>'d, it would not be called
again in the circuit apps. (Note, of course, that the Big App would ALSO
have this <cfparam>d, so that if it were made part of an even BIGGER APP...)
-----Original Message-----
From: Nat Papovich [mailto:[EMAIL PROTECTED]]
Sent: Friday, October 06, 2000 6:06 AM
To: Fusebox
Subject: RE: Multiple app_globals includes?
Ah, beauty. It's why I'm in this business. Seriously.
Well you set up your relationship between circuit apps and home apps
differently than a lot of people out there, me included. I do cflocations to
get from circuit to circuit. You keep everything alive in the home app, via
cfincludes. You're a braver man than I (obviously).
So THAT, folks, is the way Hal can get away with a single myGlobals. By
using cfparams, the global variables are set at the highest level and just
get "tossed aside" for the lower-level myGlobals. But, if any lower-level
myGlobals (no matter where it lives in the nest) need to initialize a few
local-ish params, well by golly they can do it just fine. No problems occur
unless they try to param a var that a higher-level myGlobals already
paramed. That's the way it should be. If an app works real hard and makes
it's way higher up the hierarchy, it's vars should be taken at a higher
priority.
BUT! my ferret-fingered friend. I have another question!
Steve's circuit uses a variable called request.stateslist, which is a list
of states, retrieved from a DB and stored in an application var, then
converted to request in myGlobals. And Nat's circuit uses the same variable
list. And, believe it or not, so does Hal's! Now we've got 3 pieces of
abso-friggin-lutley identical code in three separate places. Steve, Hal, and
Nat get together one day and notice that their boss hasn't figured out how
to store this variable in a higher location and they can just reference it,
without having to call it in each app. Yeah, I know that if the main home
app calls it, the sub-apps don't have to call it themselves, but there's a
tradeoff between modularity (my app lives without anything higher needed)
and modularity (all these circuit apps use the same bit of code to get their
stateslists).
Eh? Am I missing something?
Nat Papovich
ICQ 32676414
"If it was hard to write,"
says the Real Programmer,
"it should be hard to understand."
-----Original Message-----
From: Hal Helms [mailto:[EMAIL PROTECTED]]
Sent: Friday, October 06, 2000 2:50 AM
To: Fusebox
Subject: RE: Multiple app_globals includes?
Well, let's see if I can use my impressive ninth degree, ferret-style
technique to dazzle and amaze you while I make off with your wallet...
About relying on find-and-replace, I never do this. Here's what happens...
I start with a simple circuit app called "Cart". myGlobals.cfm in the Cart
directory says this...
<cfparam name="self" default="index.cfm">
<cfparam name="mainApp" default="Cart">
(mainApp is just a silly example...it doesn't mean anything.)
Now here's the fusebox for "Cart"
<cfswitch expression = "#ListLast( attributes.fuseaction, '.' )#">
<cfcase value = "someFA">
<cfset RFA.submitForm = "crt.someOtherFA">
<cfinclude template="myTemplate.cfm">
</cfcase>
<cfcase value = "someOtherFA">
<cfset RFA.submitForm = "crt.someFA">
<cfinclude template="myTemplate.cfm">
</cfcase>
I run this as a standalone circuit app. If myTemplate.cfm is set up for it,
it will tell me that self is \Cart\index.cfm and mainApp is "Cart". I'm
happy. I give it to my boss who, unbeknownst to me has decided to
incorporate this into a bigger application. Some guy named "Nat" has written
the myGlobals.cfm and the index.cfm for this home application and they look
like this:
myGlobals.cfm
<cfparam name="self" default="index.cfm">
<cfparam name="mainApp" default="NatApp">
index.cfm
<cfswitch expression="#ListFirst( attributes.fuseaction, '.' )#">
<cfcase value="crt">
<cfinclude template="Cart/index.cfm">
</cfcase>
Nat runs this as a standalone circuit app. If myTemplate.cfm is set up for
it, it will tell him that self is NatApp\index.cfm and mainApp is "NatApp".
Nat's happy. He gives it to his boss who, unbeknownst to him has decided to
incorporate this into a bigger application. Some guy named "Steve" has
written the myGlobals.cfm and the index.cfm for this home application and
they look like this:
etc...
You get the point.
So there's self defined always as the home application's fusebox (as I think
it clearly should be). There's no global find-and-replace. You undoubtedly
noticed how nice it was to use RFAs instead of hard-coding the ACTION
property of myTemplate's form with conditionals. Here, the fusebox is
changed only -- and if you're like me in not wanting any kind of global
replaces, that's got to be attractive.
You also noticed the dot prefix notation for nesting fuseboxes. That works
nicely, too. (If you go to www.roomstogokids.com and start messing around
with it, you'll see these showing up in URL links).
As for the app_server files, same thing. Whatever is the parent app takes
precedent over all others. Kind of a reverse inheritance thing. No global
replaces.
There are two things I want to change about this scheme. First, the
ListFirst and ListLast would have to be changed when going from circuit to
home app. I don't like that. I wrote a custom tag to keep track of that
without having to change the code, but I haven't shown it here.
The other thing that needs to be fixed is what to do in case of multiple
nestings with the dot prefix. There's a solution for this and I'm
incorporating it into a custom tag so that every fusebox would just have
<cf_NestedFuseboxes myPrefix="xxx">, but I haven't finished that yet.
Other than that, my friend, it's a thing of beauty and THAT, as we all know,
is a joy forever.
-----Original Message-----
From: Nat Papovich [mailto:[EMAIL PROTECTED]]
Sent: Friday, October 06, 2000 3:25 AM
To: Fusebox
Subject: RE: Multiple app_globals includes?
Well why the heck ain't we all doing it thataway? Oh I know...
Because if we rely heavily on application/global-kinda variables (whether
they be in request or application scopes) then your model of myGlobals
handling local AND global settings means that everytime I wanna change one
of those variables, I have to rely on CFStudio's global find-and-replace to
change all of them, in all the different myGlobalses. Sounds like a weak
solution. Solve one problem, introduce another.
Many people are steering away from using global variables at all, but that's
no good either. Tell me Hal, where do you set your infamous #self# variable?
In myGlobals? What if you wanna change it? What's the point of having it
variable-ized? Change it once in app_Globals, not again and again in
myGlobals.
Okay, and what about so many folks' app_server files (I got one too), that
contain information about the entire server, like mappings and drive letters
and cool junk like that. Sometimes those files grow out of neccessity due to
poor design choices made, but nonetheless, I don't think multiple
myGlobalses will solve that problem. They would if you cfincluded an
app_server file, but that's exactly NOT your point with this whole thing.
Each one of your circuits is completely standalone.
I KNOW you've got a sneeky answer up yer sneeky sleeve, and you're just
baiting me into your tiger's pit (You all did know that Hal is a black belt
in Animal Kung-Fu, Tiger Style, right? Grrr, baby!).
Waiting patiently to be made a fool,
Nat Papovich
ICQ 32676414
"If it was hard to write,"
says the Real Programmer,
"it should be hard to understand."
-----Original Message-----
From: Hal Helms [mailto:[EMAIL PROTECTED]]
Sent: Thursday, October 05, 2000 4:07 PM
To: Fusebox
Subject: RE: Multiple app_globals includes?
Yes, that's exactly right, Nat. I really like--both from an aesthetic and a
practical POV--not having to make any wholesale changes to myGlobals in
either home or circuit app context.
-----Original Message-----
From: Nat Papovich [mailto:[EMAIL PROTECTED]]
Sent: Thursday, October 05, 2000 2:26 PM
To: Fusebox
Subject: RE: Multiple app_globals includes?
Well, Hal -
Where is your cfapplication tag? In each myglobals, in each circuit, wrapped
in a
cfif not isdefined(applicaition.applciationname)
cfapplicaiton blah
/cfif
Lemme know, eh?
NAT
Nat Papovich
ICQ 32676414
"If it was hard to write,"
says the Real Programmer,
"it should be hard to understand."
-----Original Message-----
From: Hal Helms [mailto:[EMAIL PROTECTED]]
Sent: Thursday, October 05, 2000 9:54 AM
To: Fusebox
Subject: RE: Multiple app_globals includes?
Understand that Fusebox is still developing -- and during the developing of
anything, you want to encourage experimentation. To quote Chairman Mao, "Let
a thousand flowers bloom." This means that standards need to be loose.
As to the myGlobals, it's something I use in place of app_Locals and
app_Globals for just the reason you're referrring to. Every app has one.
Because myGlobals may have been called at a higher level, I usually wrap the
constants in <CFPARAM>. This makes sure they are only set once.
-----Original Message-----
From: Marc Funaro [mailto:[EMAIL PROTECTED]]
Sent: Thursday, October 05, 2000 11:47 AM
To: Fusebox
Subject: RE: Multiple app_globals includes?
Well geez, now *I* am confused. This is the first I've ever heard of
myGlobals. Why am I not able to hit the web and SEE and DOWNLOAD an
up-to-date, relevant document about the fusebox standard? And as of yet,
there's been no real documentation on app_Server, either. I hope this is
all discussed in the BOOK!! ;)
how is using myGlobals any different? It still is just one file, which
provides top-level constants, and must exist somewhere in the directory
structure, and without it a circuit app would still break. I have been, and
apparently remain, very confused about the idea of "turning a whole
application into a custom tag". Fusebox has been a tremendous help to me in
so many other areas that I haven't really worried about this particular
topic, but it seems that there are too many things that have to be "just
right" in order to object-ize an entire application. I still have trouble
wrapping my head around the problem of even coming up with an example of how
I could turn any of my applications into custom tags... they are all
large-scale, complex applications that stand on their own. Fusebox has made
them easier to develop and maintain, but as far as encapsulation of entire
apps, I am just lost.
I really am more confused on this than I thought. HELP!!
M
-----Original Message-----
From: Hal Helms [mailto:[EMAIL PROTECTED]]
Sent: Thursday, October 05, 2000 11:30 AM
To: Fusebox
Subject: RE: Multiple app_globals includes?
This is why I suggest using the more generic file "myGlobals.cfm". It works
whether as the home app -- or nested down 12 levels.
-----Original Message-----
From: Avi Flax [mailto:[EMAIL PROTECTED]]
Sent: Thursday, October 05, 2000 11:26 AM
To: Fusebox
Subject: RE: Multiple app_globals includes?
So, Marc, then it seems to me that a Circuit Application cannot be easily
switched to a Main FuseBox application - the file app_locals.cfm would have
to be renamed to app_globals.cfm, and the CFINCLUDE changed, at the very
least, is that correct?
Isn't this contrary to the idea of code reuse? I thought FuseBox allowed
for the nesting and plugging-in and plugging-out of multiple nested
applications, which could be stand-alone or circuits?
Could someone clear this up for me?
Thanks!
Avi
At 10:05 AM 10/5/2000 -0400, you wrote:
>Hi Avi,
>
>I'll jump in here on this one. You are misusing the "app_Globals" file.
>
>There should be only ONE app_Globals file in your directory structure --
>usually in the root.
>
>Then, each circuit application (subfolder) should contain an "app_Locals"
>file which then directly calls the "app_Globals" file in the root of your
>APPLICATION.
>
>This way, in ANY given circuit application, the fusebox calls the
app_locals
>file which contains constants and rules for THAT circuit application, and
>then calls the "app_Globals" file, which contains the constants and rules
>for the entire application.
>
>Marc Funaro
>
>-----Original Message-----
>From: Avi Flax [mailto:[EMAIL PROTECTED]]
>Sent: Thursday, October 05, 2000 9:47 AM
>To: Fusebox
>Subject: Multiple app_globals includes?
>
>
>I've had this question for a little while now and I'm tired of waiting for
>the book or a FAQ. So here goes: When I have multiple nested FuseBox apps
>(I call them FuseApps), how do you deal with a situation where you need
>certain code to execute with every single page access, no matter where? I
>got the impression from the FuseBox spec that we want to avoid using
>Application.cfm so that we can use our FuseApps as Modules (which I still
>haven't seen the need to do) - so fine, I include an app_globals in the
>root of each app (included by the FuseBox (index.cfm)) . I have each
>app_globals file in each nested directory including the one in the
>directory above it:
>
>So:
>
>root/index.cfm includes root/app_globals.cfm
>
>root/products/index.cfm includes products/app_globals.cfm, which includes
>root/app_globals.cfm
>
>root/products/wheels/index.cfm includes app_globals.cfm, which includes
>products/app_globals.cfm, which includes root/app_globals.cfm
>
>End result of all of this is that every time I access a page in the deepest
>level, 12-15 files are being processed by the CF Server! This has GOT to be
>a performance hit, and not the most efficient way to do this.... Can't we
>just use application.cfm.... or can someone demonstrate why it is
>preferable not to?
>
>While I am writing, is it appropriate to move control of the browser from
>one app to a subapp using CFLOCATION, or are we supposed to stick to using
>CFINCLUDE every time, no matter what, and have the root FuseBox control
>everything - I am not sure, but I think I noticed the eBags site using
>CFLOCATION to move to subdirectories.
>
>Thanks!
>Avi
>
>---------------------------------------------------------------------------
-
>--
>To Unsubscribe visit
>http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/fusebox or
>send a message to [EMAIL PROTECTED] with 'unsubscribe' in
>the body.
>
>---------------------------------------------------------------------------
---
>To Unsubscribe visit
>http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/fusebox or
>send a message to [EMAIL PROTECTED] with 'unsubscribe' in
>the body.
----------------------------------------------------------------------------
--
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/fusebox or
send a message to [EMAIL PROTECTED] with 'unsubscribe' in
the body.
----------------------------------------------------------------------------
--
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/fusebox or
send a message to [EMAIL PROTECTED] with 'unsubscribe' in
the body.
----------------------------------------------------------------------------
--
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/fusebox or
send a message to [EMAIL PROTECTED] with 'unsubscribe' in
the body.
----------------------------------------------------------------------------
--
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/fusebox or
send a message to [EMAIL PROTECTED] with 'unsubscribe' in
the body.
----------------------------------------------------------------------------
--
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/fusebox or
send a message to [EMAIL PROTECTED] with 'unsubscribe' in
the body.
----------------------------------------------------------------------------
--
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/fusebox or
send a message to [EMAIL PROTECTED] with 'unsubscribe' in
the body.
----------------------------------------------------------------------------
--
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/fusebox or
send a message to [EMAIL PROTECTED] with 'unsubscribe' in
the body.
----------------------------------------------------------------------------
--
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/fusebox or
send a message to [EMAIL PROTECTED] with 'unsubscribe' in
the body.
----------------------------------------------------------------------------
--
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/fusebox or
send a message to [EMAIL PROTECTED] with 'unsubscribe' in
the body.
----------------------------------------------------------------------------
--
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/fusebox or
send a message to [EMAIL PROTECTED] with 'unsubscribe' in
the body.
------------------------------------------------------------------------------
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/fusebox or send a
message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
