I think Hal is more suggesting that you cfinclude, rather than cflocate -
thus eliminating the argument altogether... I've followed his proposed
methods of nesting (read: including) sub-circuits and it works like a
dream... a current project that I'm working on leans quite heavily upon the
"inclusion within inclusion" technique for inheritance of all manner of
needed objects created from "above".
I don't suppose you want to rewrite and simplify the whole issue.
pts
~~ -----Original Message-----
~~ From: Nat Papovich [mailto:[EMAIL PROTECTED]]
~~ Sent: Friday, October 06, 2000 9:14 AM
~~ To: Fusebox
~~ Subject: RE: Multiple app_globals includes?
~~
~~
~~ 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/f
~~ usebox 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/f
~~ usebox 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/f
~~ usebox 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/f
~~ usebox 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/f
usebox 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.
