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.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

Reply via email to