It seems that there are several ideas jumbled together
here, and that's where the confusion is.
1) Reusability: The idea that I can 'drag and drop' a new circuit
into an app.
2) Encapsulation: The idea that each circuit is self-contained,
and can be unit-tested by calling its index.cfm directly.
3) Inheritance: The idea that by nesting circuits, each child
becomes an extension of its parent.
4) Abstraction: The idea that one circuit doesn't have to know
the location of another in order to call it.
Okay, now it's starting to make a bit more sense. The nesting
feature isn't really about parent-child relationships, but
rather about superclass-subclass relationships. A subclass
can't really exist without its superclass, so #2 ought to
be thrown out. It doesn't make sense and doesn't work.
I'm not 100% confident about the abstraction idea either. Each
circuit within an application has an alias that is unique
within the scope of the entire application. This allows us
to move circuits around without messing up the circuits that
call them. But that messes up the inheritance structure. If I
have a class MiniHal that extends the class Hal, and then I
"move" it so that it extends the class StanCox instead, it's
not really the same class, is it?
It's as if Hal forgot why he created the nesting when he
invented circuits.cfm. Or maybe the idea of inheritance was
brought in after circuits.cfm. Eiher way, the two ideas are
disconnected.
And then there's this rediculous notion of reusability.
Nesting breaks the enapsulation of circuits, and therefore
seems to make code less reusable. (However, I've found
XFA's to be invaluable.)
Please don't get me wrong. I'm not trying to bash anyone's
methodology. I'm trying to understand it. Once I understand
the advantages, I'll be able to determine if it suits my
needs. And if there really are serious problems, I know
you guys will eventually start seeing what I'm seeing. And
then maybe we can even improve upon HAL9000.
Patrick
> Well it seems to me that the main advantage of using circuits.cfm, and
> avoiding fully-qualified fuseactions, is that the developer
> doesn't have to
> concern himself or herself with the details of the structure. I
> know I can
> call a circuit called login, without needing to know that it's
> actually at
> home.library.security.login
> These details are handled by the circuits.cfm, which provide a layer of
> abstraction between developer and hierarchy.
>
> And yes, the code for dealing with a fully-qualified fuseaction
> is certainly
> simple. Hal's code actually takes the single-dimension fuseaction and
> translates it into a fully-qualified fuseaction. The difficult
> thing is not
> DEALING with a fully-qualified fa, but in CREATING the
> fully-qualified fa in
> the first place. eg., when I'm in the code for my
> customisePortal circuit,
> how do I refer to the login circuit. At the moment, I just call
> it "login",
> and let the circuits.cfm code handle it. But if I have to make a
> fully-qualified call, then I need to know what the home app is, and
> calculate the fully-qualified location of login relative to the
> home app.
> That sounds like hard work, and I don't really want to deal with
> that, but
> it all gets taken care of for you in Hal's XFB. Consider me a
> convert. I
> once was lost, but now am found...
>
> Actually, I am just posting my CF_XFB tag and associated stuff on
> Bjork.net.
> I think they make XFB just a little simpler in practice, without
> sacrificing any of the philosophical goodies. Please have a look.
>
> Thanks,
> LBB.
>
>
>
>
> >From: "Patrick McElhaney" <[EMAIL PROTECTED]>
> ...>
> >Every time a layer is peeled off and we move down to the next circuit,
> >the variable ctx would be updated. So if grandparent is my home app,
> >ctx would be set to 'parent' and then to 'parent.child'.
> >
> >So if I have the following code in child:
> ><cflocation url="#self#?fuseaction=#ctx#.dosomething">
> >I'll relocate to
> >/grandparent/index.cfm?fuseaction=parent.child.dosomething
> >
> >If parent is the home app, the same code would relocate to
> >/grandparent/parent/index.cfm?fuseaction=child.dosomething
> >
> >And if child is itself the home app...
> >/grandparent/parent/child/index.cfm?fuseaction=.dosomething
> >
> >The code to do this is simpler than Hal's.
> ....
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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
