Surely there are coordination issues when modules have to work together, but
consider whether it's easier to coordinate the few global variables set in
different circuit apps v. requiring each fuse coder to know all the
specifics of all circuit apps. Without a model where the application is
smart enough to direct messages sent to it to the appropriate circuit app,
each coder has to have a full understanding of all circuit apps -- if only
to know where to cflocate to. In an application that is large/complex and
that has distributed developers, that becomes a crippling requirement.
-----Original Message-----
From: BOROVOY Noam [mailto:[EMAIL PROTECTED]]
Sent: Monday, October 09, 2000 6:15 AM
To: Fusebox
Subject: RE: Multiple app_globals includes?
The concept is neat, BUT the idea of reducing interdependence kind of
crashes when using includes as if you have globals included at each level
you still have the dangers of values being stepped on.
The CFPARAM only works for the specific variable names that all circuits
agreed on ahead of time, but what about those little circuit specific
globals having name conflicts?
Noam
----------
From: Hal Helms [SMTP:[EMAIL PROTECTED]]
Sent: Friday, 06 October 2000 12:43
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.
------------------------------------------------------------------------------
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.
