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.
