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.
