http://www.fusebox.org/specifications/extendedfusebox/Extended_Fusebox_101.d
oc
Phil
-----Original Message-----
From: George Kaytor [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, March 07, 2001 8:36 AM
To: Fusebox
Subject: RE: Extended Fusebox -- A bump in the road....
I know this is a repeat, but where can I find the whitepaper on extended
fusebox. I checked on hal helms site but couldn't find a link for it.
thanks,
-george
>From: "Mike Craig" <[EMAIL PROTECTED]>
>Reply-To: [EMAIL PROTECTED]
>To: Fusebox <[EMAIL PROTECTED]>
>Subject: RE: Extended Fusebox -- A bump in the road....
>Date: Wed, 07 Mar 2001 07:44:46 -0500
>
>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.direc
t
>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