I think I'm starting to understand where you guys are coming from.
There's nothing wrong with circuits.cfm. It solves a problem. But I
think I have a better solution to that problem.
If the circuit "orderTracking" wants to call is own fuseaction,
"viewOrder", it does so in this form:
#self#?fuseaction=#this#.viewOrder
If cart wants to call it, the syntax is
#self#?fuseaction=#this#.orderTracking.viewOrder
If an app containing cart wants to call it:
#self#?fuseaction=#this#.cart.orderTracking.viewOrder
#this# is a special variable that represents the circuits in which
the current circuit is nested. I explained it all in an earlier post.
You don't need to know the absolute path to the fuseaction you're
calling, only the relative path.
Does that make sense?
Patrick
> -----Original Message-----
> From: Toby Tremayne [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, April 05, 2001 10:41 PM
> To: Fusebox
> Subject: RE: Nesting circuits: I just don't get it! :(
>
>
> Again maybe I'm being too simplistic - but Patrick what you're describing
> pretty much precludes the whole idea of not needing to know anything about
> the structure of the rest of the app... Using fully qualified names like
> that means a lot of recoding if yo udo move things about. With
> you example
> of the shopping cart etc - what happens when you want to include
> that entire
> app into another app or three? You'll need a different directory
> structure
> there, and if every circuit is forced to relate to every other circuit by
> KNOWING THE ENTIRE DIRECTORY STRUCTURE (scuse caps, can't use
> underline <g>)
> then there's a lot of farting about to get them to talk to each other.
>
> circuits.cfm means I can conmbine any number of fuses and circuits written
> by any number of developers in any number of countries - none of whom know
> anything whatsoever about any of the others - with NO EXTRA EFFORT. makes
> sense to me...
>
> Toby
>
> Toby Tremayne
> Code Poet and Zen Master of the Heavy Sleep
> Show Ads Interactive
> 359 Plummer St
> Port Melbourne
> VIC 3207
> P +61 3 9245 1247
> F +61 3 9646 9814
> ICQ UIN 13107913
>
> -----Original Message-----
> From: Patrick McElhaney [mailto:[EMAIL PROTECTED]]
> Sent: Friday, 6 April 2001 12:44 AM
> To: Fusebox
> Subject: RE: Nesting circuits: I just don't get it! :(
>
>
> > Hi Patrick,
> >
> > My main reason for using circuits.cfm is to shield the developer
> > from stuff
> > that he does not need or want to know. If I want to call the "login"
> > sub-app, I just need to know that its name is "login". I simply
> > DO NOT want
> > to know that it is actually located at
> /apps/library/security/login. Even
> > worse, I don't want to have to change all of my code when the system
> > architect decides to move /apps/library/security/login to
> > /apps/library/cfml/security/login.
>
>
> I don't see a reason to go moving circuits around after you've snapped
> them together. Suppose I have a circuit that looks like this:
> cart/
> cart/shop/
> cart/checkout/
> cart/orderTracking/
> cart/admin/
>
> Basically, it's a standard shopping cart app, right? It doesn't make
> sense to put all of its many functions in one circuit, so I broke
> out the four basic use cases into nested circuits. This app
> functions as a stand-alone, but the real intention is to nest it in
> a larger application.
>
> Once the "cart" application is nested in a larger application do
> its five circuits become independent of each other? Would
> it make sense for me to move the "checkout" circuit to another
> part of the larger application? Would it still be valid outside
> of "cart"?
>
> Obviously, it's very important to you to be able to move circuits
> around after they've been snapped together -- and furthermore that
> this can be done in a routine fashion -- but I just don't see
> the motivation for it. Having mulled over it for days, I still
> can figure out what I'm missing.
>
>
> > in short, there ARE great
> > advantages to
> > using a two-part name.
> Advantages? With an 's'? So what are the others? :)
>
> > Circuits.cfm has other side-benefits, eg it provides and
> centralizes a map
> > of the system.
> That's a circular argument. The only map it provides is the one
> it creates a need for. :)
>
> > So let us throw you the obvious reply:
> >
> > Why would you WANT to refer to a circuit by its fully-qualified name?
>
> 1) It's a simpler, more direct approach to the problem. Its kind of like
> saying, "I'm from USA.NC.CHARLOTTE" vs. "I'm from City Code 'CLT'
> and here's
> a spreadsheet that maps city codes to their
> nation.state/province.fullname."
> That's the main reason. When all other things are equal, the KISS
> principle applies.
>
> 2) I don't want to bother with creating and maintaining another file
> (circuits.cfm) if I don't have to.
>
> 3) Context matters. Store.Cart.Admin makes more sense to me than
> 'admin', 'adm', or whatever. (And no, you can't call it
> 'store_cart_admin', because that defeats the premise of abstracting
> away the location.)
>
> 4) I can literally drag and drop new circuits into an app and have
> them work without any changes.
>
> 5) I don't have to worry about confusing two different circuits with
> similar names.
>
> 6) Makes it impossible to violate a circuit's encapsulation. A circuit
> should only be able to directly refer to itself and its descendants.
> (Of course, it can have XFA's passed up from its ancestors that refer
> to circuits outside of its scope.)
>
> 7) If I introduce a new circuit with the same name as an existing
> circuit, I'm don't have to rename it. And as a result, I don't have
> to go and find any fuseactions that point to the old name and update
> the code.
>
> 8) A special variable would refer to the current circuit.
> (for example, <cfset xfa.submitForm = "#this#.addProduct">) That
> prevents me from having to remember what the current circuit's
> name is, and makes it clear when a circuit is referring to itself.
>
> Okay guys, the ball's in your court. What are the other advantages
> to two-part names? Let's weight the pros and cons.
>
>
> Patrick
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Structure your ColdFusion code with Fusebox. Get the official book at
http://www.fusionauthority.com/bkinfo.cfm
Archives: http://www.mail-archive.com/[email protected]/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
