I don't really have the time to rewrite it all to make it as clear as it
should be -- I'm just too slammed right now. But, in all seriousness, the
purpose for GOOD training (as opposed to...um...some other training out
there) is to put the student in situations where they are guided to work
with (not just hear or "copy this in your browser") techniques and methods.
Otherwise, who's got the time to (a)understand every new idea and (b)set up
a test environment while (c)performing metrics on it and (d)evaluating it?
This really isn't a plug for my training -- but it IS an unabashed plug for
training that trains instead of lectures students.
As in many things, Albert Einstein said it best, "Learning by doing isn't
just one way of learning; it's the only way."
PS My son reminded me last night of that great line from the movie "Mystery
Men": "He who questions training only trains himself in asking questions."
If you've seen the movie, you'll remember the mystic teacher who's always
spouting nonsense like this.
-----Original Message-----
From: Peter Terhorst [mailto:[EMAIL PROTECTED]]
Sent: Friday, October 06, 2000 12:50 PM
To: Fusebox
Subject: RE: Multiple app_globals includes?
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.
------------------------------------------------------------------------------
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.
