Jeff,
I think I know exactly what you're talking about. At one point,
I was thinking along the same lines. But now I don't think it
will really work.
Say you have an admin circuit under cart, and you want to move
it somewhere else. How will you update your circuits.cfm in
cart to point to the new location of admin? You can't.
I decided I would get around that by just making my basic
framework very rigid and not move things around a lot after
they've been snapped together. It's okay that the framework
is rigid, because I use XFAs and other parameters to
change how the application works. It might require me to
put a little more thought into the design phase, but that's
never a bad thing. ;-)
Because I won't move circuits around (at least not without
a trip back to the drawing board) I have no need for
circuits.cfm.
And as a result, the design is much simpler.
Patrick
> -----Original Message-----
> From: Jeff Peters [mailto:[EMAIL PROTECTED]]
> Sent: Friday, April 06, 2001 10:19 AM
> To: Fusebox
> Subject: RE: Nesting circuits: I just don't get it! :(
>
>
> Even better is a method I'm tinkering with, which uses a call like this:
>
> #request.self#?fuseaction=#request.fusePrefix#cart.viewOrder
>
> I use a variation on circuits.cfm to build request.fusePrefix
> based on the
> fusebox's location relative to another app (or lack thereof).
> This provides
> three benefits:
> 1. All fusebox calls look exactly the same, except for the
> fuseaction itself.
> 2. If the circuit is popped into another application or used standalone,
> there's no need to mess with the calls; circuits.cfm handles it for you.
> 3. The way I build the fusePrefix, the circuit only cares that its alias
> ("cart" in the example above) is unique within itself, not
> necessarily within
> the entire parent application. With this method, a nested
> structure where two
> apps happen to have the same alias is valid, so again you don't
> have to worry
> about the parent app environment.
>
> I'm not happy that I've considered all the permutations of this
> method yet, but
> it's the direction I'm currently leaning.
>
> - Jeff
>
> On 6 Apr 2001, at 9:29, Patrick McElhaney wrote:
>
> > 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
>
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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
