Actually, no...and uh...you have a good point that I had not considered.
Technically, if I am getting the usage right, say I was five levels deep. I
believe that my fuseaction would be 1.2.3.4.5.fuseaction since everything is
technically routed through the main app's index.cfm. If I simply put
5.fuseaction and called index.cfm the circuit for "5" would not exist in the
main app's circuit structure, only 2 would and 2's would contain 3 and 3's
....etc. I think that is how it would work. But that does not make any
sense to me because then you could not program self contained circuits as
applications only to move them into a tree later. I guess I am a little
confused in this too. I will need to look a little further. Oh wait a
second...isn't that why we use "#self#" as an indicator for index.cfm so
that #self#?fuseaction=5.actiontotake would only look as far as itself (the
current circuit)? I still need to look a little further. Sorry...not as
lucid as I was, er, this morning. Need coffee.
Oh...not I think I remember. If the circuit were stand alone you would
reference its contents as 5.home or 5.about or 5.whatever. But as Hal Helms
points out in his white paper, if you tie a stand alone xfb app into and
existing xfb app, if is your responsibility to include a reference at the
root circuit controller for that new circuit. This way, even if you go five
deep, your main circuit would have a reference like:
request.circuits.5 = "1.2.3.4";
which would otherwise not have existed. Sorry that was such a mess...you
know I was up late dodging my own customers for a while. But I think the
ultimate answer to your question is yes...this was just a round-about way of
saying it...but I feel better now.
Mike
-----Original Message-----
From: Sean Renet [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, March 07, 2001 4:41 AM
To: Fusebox
Subject: Re: Extended Fusebox -- A bump in the road....
Thanks mike I get it. its so your XFA's are always persistant with the
subapplication and your fuseactions aren't
directory.directory.directory.directory.directory.directory.directory.direct
ory. Is that why?
----- Original Message -----
From: "Mike Craig" <[EMAIL PROTECTED]>
To: "Fusebox" <[EMAIL PROTECTED]>
Sent: Wednesday, March 07, 2001 12:03 AM
Subject: RE: Extended Fusebox -- A bump in the road....
> If I can explain this correctly, using the Nesting and Circuits templates
> allows you to identify all the circuits at an application level and
nesting
> helps navigate it. So If I am at my topmost home app circuit, I might
have
> a fuseaction of myapp.profile, but if I am in the profile app I might have
a
> fuseaction of profile.basicinfo. When the basicinfo fuseaction is needed,
> we start again at the root application where the fuseaction gets
translated
> into myapp.profile.basicinfo where now nesting (in coordination with the
> listdeleteat you mention) can traverse a directory structure figuring
myapp
> is my root, profile is a circuit under that and basicinfo is what I want
to
> do. At each circuits level, the index.cfm strips away those layers to
> finally get to where you want to be.
>
> Does that help explain it all?
>
> Mike
>
> -----Original Message-----
> From: Sean Renet [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, March 07, 2001 2:30 AM
> To: Fusebox
> Subject: Re: Extended Fusebox -- A bump in the road....
>
>
> okay I found it. Unless I am missing something, that seems like a lot
more
> work and code than putting
> <cfset attributes.fuseaction = listdeleteat(attributes.fuseaction,1,".")>
> in app_locals and using listfirst on all of the index pages. Is there some
> reason I am missing for using all of that code?
>
>
> ----- Original Message -----
> From: "Sean Renet" <[EMAIL PROTECTED]>
> To: "Fusebox" <[EMAIL PROTECTED]>
> Sent: Tuesday, March 06, 2001 11:03 PM
> Subject: Re: Extended Fusebox -- A bump in the road....
>
>
> > no. what is it? where do I find that?
> > I can't seem to find anything I need there reguarding XFB. I pulled the
> > methodology out of his occasional CF newsletter.
> > ----- Original Message -----
> > From: "Nat Papovich" <[EMAIL PROTECTED]>
> > To: "Fusebox" <[EMAIL PROTECTED]>
> > Sent: Tuesday, March 06, 2001 9:11 PM
> > Subject: RE: Extended Fusebox -- A bump in the road....
> >
> >
> > > Are you using circuits.cfm as per Hal's suggestion from his site?
> > >
> > > > -----Original Message-----
> > > > From: Sean Renet [mailto:[EMAIL PROTECTED]]
> > > > Sent: Tuesday, March 06, 2001 7:28 PM
> > > > To: Fusebox
> > > > Subject: Extended Fusebox -- A bump in the road....
> > > >
> > > >
> > > > Okay how does XFB handle nested applications?
> > > >
> > > > For example
> > > >
> > > > The fuseaction admin.home would take me to the directory admin
> > > > and then find
> > > > the fuseaction home on the index.cfm.
> > > >
> > > > So now we are in the /admin folder
> > > >
> > > > This folder has subdirectories for say PEOPLE, DEPARTMENTS,
PROJECTS,
> or
> > > > whatever.
> > > >
> > > > Each sub directory is its own application and in so much has its own
> > > > fuseactions.
> > > >
> > > > Now normally I would handle this by having a cascading list of
> > fuseactions
> > > > in the index.cfm switches
> > > >
> > > > That is on the root index.cfm I would have
> > > >
> > > > <cfcase value="admin,adminValidate,adminThis,AdminThat,"
> delimiters=",">
> > > > <cfinclude template="admin/index.cfm">
> > > > </cfcase>
> > > > <cfcase value="Adminprojects,AdminprojectsThis,AdminprojectsThat"
> > > > delimiters=",">
> > > > <cfinclude template="admin/index.cfm">
> > > > </cfcase>
> > > > <cfcase
> > value="Admindepartments,AdmindepartmentsThis,AdmindepartmentsThat"
> > > > delimiters=",">
> > > > <cfinclude template="admin/index.cfm">
> > > > </cfcase>
> > > > <cfcase value="Adminpeople,AdminpeopleThis,AdminpeopleThat"
> > > > delimiters=",">
> > > > <cfinclude template="admin/index.cfm">
> > > > </cfcase>
> > > > --The reason I use 3 separate cases is so that I can easily disable
> the
> > > > fuses.
> > > >
> > > > In the admin folder the nested applications would be like this:
> > > >
> > > > <cfcase value="Adminprojects,AdminprojectsThis,AdminprojectsThat"
> > > > delimiters=",">
> > > > <cfinclude template="projects/index.cfm">
> > > > </cfcase>
> > > > <cfcase
> > value="Admindepartments,AdmindepartmentsThis,AdmindepartmentsThat"
> > > > delimiters=",">
> > > > <cfinclude template="departments/index.cfm">
> > > > </cfcase>
> > > > <cfcase value="Adminpeople,AdminpeopleThis,AdminpeopleThat"
> > > > delimiters=",">
> > > > <cfinclude template="people/index.cfm">
> > > > </cfcase>
> > > >
> > > > So to do the same thing in EXB, you would have to have
> > > > fuseactions that look
> > > > like admin.projects.projectsThis
> > > >
> > > > So using ListLast(attributes.fuseaction,'.') and
> > > > ListFirst(attributes.fuseaction,'.') in the index pages doesn't
work.
> > > >
> > > > One of the reasons I use fusebox is because I subcontract a lot of
> work.
> > > > Some of those subcontracted apps, themselves have mini apps. The way
I
> > am
> > > > currently integrating this allows for two things:
> > > >
> > > > a) individual directory security that is cfapplication based and
LDAP
> > > > integrated.
> > > > b) the ability to just plugin apps no matter how many
> > > > subapplications/directories they contain
> > > >
> > > > So, how is this handled in XFB? I really like the idea of XFB, but
> this
> > > > seems to be a bump in the road. Do we just make a tag that drops
> > > > the first
> > > > thing in the list in each subdirectory? And always use
> > > > ListFirst(attributes.fuseaction,'.') in all index.cfm's
> > > >
> > > > That is:
> > > > a fuseaction that is admin.projects.projectsThis
> > > >
> > > > /
> > > > --- index.cfm----
> > > > <cfswitch expression="#ListFirst(attributes.fuseaction,'.')#">
> > > > <cfcase value="admin" delimiters=",">
> > > > <cfinclude template="admin/index.cfm">
> > > > </cfcase>
> > > > </cfswitch>
> > > >
> > > > /admin
> > > > --- index.cfm----
> > > > <cfset attributes.fuseaction = listdeleteat(attributes.fuseaction,
1)>
> > > >
> > > > ----the fuseaction becomes projects.projectsThis---
> > > >
> > > > <cfswitch expression="#ListFirst(attributes.fuseaction,'.')#">
> > > > <cfcase value="projects" delimiters=",">
> > > > <cfinclude template="projects/index.cfm">
> > > > </cfcase>
> > > > </cfswitch>
> > > >
> > > > /admin/projects
> > > > <cfset attributes.fuseaction = listdeleteat(attributes.fuseaction,
1)>
> > > >
> > > > ----the fuseaction becomes projectsThis---
> > > >
> > > > <cfswitch expression="#ListFirst(attributes.fuseaction,'.')#">
> > > > <cfcase value="projectsThis" delimiters=",">
> > > > <cfinclude template="dsp_projects.cfm">
> > > > </cfcase>
> > > > </cfswitch>
> > > > And so on down the tree.....
> > > >
> > > > So maybe a tag that you put in all of the top level fuseactions,
> > > > and if the
> > > > fuseaction isn't contained in that list it drops the first thing in
> the
> > > > fuseaction list. Then this tag could be located on app_locals.cfm
> > > > of any sub
> > > > application.
> > > >
> > > >
> > > > Sean Renet
> > > >
> > > >
> > >
> >
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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
