Hi all,
Well, i guess to understand this methodology perfectly, may be we could all
comment on this little project so as to share our views.
(zip file attached!)
In this project, there are 10 circuits:
- home application(nestedfuseboxes)
-products
-magazines
- sellers
- vendors
-books
-search
-users
- registered
- administrators
Project Key points:
In fact, when a user enters the home application (in the index.cfm page
whereby the default fuseaction is usr.home).
He is directed to the "users circuit" to login (whereby the default
fuseaction for the index.cfm of the "users circuit" is home,login).
After Username/Password validation in the "users circuit" (pls note that in
this testing case, the user is always successfully validated no matter which
username/password entered), the user is redirected to the "products
circuits" where finally he has the choice to move to the "magazines or
books circuits" through another menu.
P.S: the other circuits have no files for the moment.
Well, here are my questions:
1) Are my circuits.cfm properly written?
2) When i am in the magazines circuits, i would surely want to navigate
within the same circuit, then (depending on whether my ideas are correct!)
why each fuseaction is redirected to the "index.cfm of the home application"
before being redirected again to the magazines circuit. I guess there is no
need to move upward, since we are in the same circuit? Pls, correct me if
i'm wrong.
3) If i want to test the circuit magazines on a stand-alone basis, how do i
proceed since i am redirected to the home application each time?
Hope that you will comment my codes?
By the way, some codes are being reproduced exactly from the example of Hal
Helms (thank you for that Hal)...
Thank you all in advance,
Sneid
-----Original Message-----
From: Toby Tremayne [mailto:[EMAIL PROTECTED]]
Sent: Monday, April 02, 2001 1:07 AM
To: Fusebox
Subject: RE: Nesting circuits: I just don't get it! :(
I don't mean to sound rude or overbearing Patrick, (and the way my
mailserver's playing up I'm probably coming late to this discussion again)
but I think you've missed the point somewhere...
I have a pretty decent sized application, with 20-30 circuits in it, I use
the XFB nesting method and I can unit test everything perfectly. I can
separate a circuit by dragging it's folder out using windows explorer and it
still works perfectly fine on it's own. I drag it back and still all is
well.
I think the "Secret" comes down to an understanding of the circuits file
itself. Your fuseactions would all be two part. circuitName.fuseaction -
with the "peeling" going on in the index file this quite simply replaces the
first element with the relevant string from the circuits structure, and then
tries to evaluate the rest. If it can't immediately discern a fuseaction
from what's left (IE listlen(fuseaction) gt 1) then it uses the first part
as a path and the process is repeated in the subsequent index.cfm
For an individual circuit, your circuits.cfm file is going to be pretty
brief. It's the circuits.cfm in the HOME application that matters to the
final build. Everything exists on a standalone basis - the abbreviations or
names you use in the circuits.cfm DON'T MATTER when the circuit is included
in a larger application - because it inherits the circuits.
What I think (perhaps erroneously) a lot of people are missing, is that
using this nesting system doesn't mean you can have a dozen circuits that
exist on their own and then just move all the folders together - it doesn't
work automatically like that. As you would with any application, you tailor
the home circuit to meet the needs of the nested circuit - IE YOU WRITE A
BIG CIRCUITS.CFM TO KEEP IN THE ROOT DIRECTORY. This contains the links to
all of your circuits, no matter how deeply they're nested. Let me give you
an example from my own website:
a circuits.cfm from a nested circuit called "library":
request.circuits = structNew();
request.circuits.lib = "library";
now if that circuit ran on it's own, it would be quite happy with just that
circuits.cfm, and a file structure like this:
e:\inetpub\wwwroot\library
here's the circuits.cfm from the HOME APPLICATION of that site:
request.circuits = structNew();
request.circuits.pl = "poetic";
request.circuits.mem = "poetic.members";
request.circuits.lib = "poetic.library";
request.circuits.frm = "poetic.forum";
request.circuits.inp = "poetic.input";
request.circuits.nfo = "poetic.info";
request.circuits.insp_find = "poetic.insp_finder";
request.circuits.insp = "poetic.inspirations";
request.circuits.ref = "poetic.reflections";
request.circuits.poem_find = "poetic.poem_finder";
request.circuits.srch = "poetic.search";
request.circuits.cont = "poetic.contemplations";
request.circuits.adm_adm = "poetic.admin";
request.circuits.adm_bak = "poetic.admin.backups";
request.circuits.adm_cont = "poetic.admin.contemplations";
request.circuits.adm_nfo = "poetic.admin.info";
request.circuits.adm_logs = "poetic.admin.logs";
request.circuits.adm_news = "poetic.admin.news";
request.circuits.adm_ref = "poetic.admin.reflections";
request.circuits.adm_insp = "poetic.admin.inspirations";
request.circuits.adm_subs = "poetic.admin.submissions";
request.circuits.adm_mem = "poetic.admin.members";
request.circuits.scr = "poetic.scripts";
and an example of the directory structure would be:
e:\inetpub\wwwroot\poetic
e:\inetpub\wwwroot\poetic\members
e:\inetpub\wwwroot\poetic\library
e:\inetpub\wwwroot\poetic\forum
get the idea?
In all honesty, you're going to have to write this file (the HOME
APPLICATION one) by hand anyways, so I don't see that deciding on a unique
name for each circuit is excessively taxing... think about it - at the very
worst you might have to walk through one index.cfm and change the prefix on
a couple of XFAs.
Have I missed something and made myself look like an enormous fool? I know
that when I was getting my head around XFB that the circuits.cfm was the
sticking point with me - once I got what it was doing I understood the lot.
I just don't see how, if you understand this principle, you could say that
it precludes encapsulation abstraction and reuse.
encapsulation:
everything in the circuit works on it's own, that's always been the
premise - right away you see there that you have encapsulation. Whether
you're using XFB or not any fusebox circuit you code should be able to run
in a similar fashion with little or no modification.
abstraction:
the circuit doesn't need to know anything about any other circuit in the
application. The HOME APPLICATION knows about everything - but isn't that
natural? How else would you set it up?
re-use:
this is kind of inherant I would have thought... the code works fine on it's
own, it STILL works when you include it in something else, therefore it's
reuseable....
I really hope I've not misread something and spent the last 10 minutes
preaching to the converted, but yeah, I had a similar problem and I know for
a fact that these goals are inherant to the nesting method... if anyone
wants, I'm happy to walk them through the code for the site...
HTH
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: Saturday, 31 March 2001 2:48 AM
To: Fusebox
Subject: RE: Nesting circuits: I just don't get it! :(
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
