• Create BookmarkCreate Bookmark
  • Create Note or TagCreate Note or Tag
  • PrintPrint
Share this Page URL
Help

Chapter 4. Handling a Fuseaction > Section 9: Children fbx_settings.cfm

Section 9: Children fbx_settings.cfm

So far, the core file has included fbx_circuits.cfm and the root fbx_settings.cfm. It has also converted attributes.fuseaction into its API counterparts: fusebox.circuit and fusebox.fuseaction. In addition, the core file has set up the path to the target circuit based on its mapping in the circuits structure. The next step is to include the fbx_settings.cfm files, in top-to-bottom order, down to the target circuit, by following the circuits structure mapping. Stripped of all the error handling, section 9 of the core file looks like this:

<cfscript> 
FB_.fullPath=ListRest(fusebox.Circuits[fusebox.TargetCircuit], "/"); 
FB_.Corepath=""; 
fusebox.thisCircuit=fusebox.HomeCircuit; 
</cfscript> 
<cfloop list="#FB_.fullpath#" index="aPath" delimiters="/"> 
  <cfscript> 
  FB_.Corepath=ListAppend(FB_.Corepath, aPath, "/"); 
  fusebox.IsHomeCircuit=FALSE; 
  fusebox.currentPath=FB_.Corepath & "/"; 
  fusebox.rootPath=repeatString("../", ListLen(fusebox.currentPath,'/')); 
  </cfscript> 
  <cftry> 
    <cfif StructKeyExists(FB_.ReverseCircuitPath, fusebox.Circuits[fusebox.HomeCircuit] & "/" & FB_.CorePath)> 
      <cfset fusebox.thisCircuit=FB_.ReverseCircuitPath [fusebox.Circuits[fusebox.HomeCircuit] & "/" & FB_.CorePath] > 
      <cfif fusebox.thisCircuit EQ fusebox.TargetCircuit> 
        <cfset fusebox.IsTargetCircuit=TRUE> 
      <cfelse> 
        <cfset fusebox.IsTargetCircuit=FALSE> 
      </cfif> 
      <cfinclude template="#fusebox.currentPath#fbx_Settings.cfm"> 
    </cfif> 
    <cfcatch>...</cfcatch> 
  </cftry> 
</cfloop> 

					  

This section does two things: It sets up each circuit’s API variables, and it calls the fbx_settings.cfm file per child circuit. Let’s take these one at a time.

Prepare the API

The first part of section 9 creates two keys in the private FB_ structure. FB_.fullPath holds the value of the target circuit’s mapping, minus the first directory. This variable is first used in the next section of the core. The fuseaction from our URL (&fuseaction=reviews.read) requests the reviews circuit whose mapping looks like this (from fbx_circuits.cfm):

fusebox.circuits.reviews="thirdwheel/catalog/products/reviews"; 

That means that FB_.fullPath will contain this value:

catalog/products/reviews 

The next key created is FB_.corePath. This variable is used during the looping in the next section to hold the value of the directory path that is currently being accessed. Right now, it’s blank; it is set and reset soon.

The next thing that this section does is set another API variable, fusebox.thisCircuit, to the value of fusebox.homeCircuit. It’s set to the home circuit because the home circuit is currently being accessed. In the next core section, other circuits are accessed. As they are, this variable is set and reset.

Following the closing </cfscript> tag, this section begins a loop. The loop is based on the list of FB_.fullpath. The core file just finished setting FB_.fullpath based on the mapping of the target circuit, like this:

catalog/products/reviews 

The <cfloop> tag uses the delimiter of / (forward slash), which means that this section will be looped three times—once for each element in the list. Each time, through, the index aPath will contain the value of the current circuit: first catalog, then products, and finally reviews.

The rest of this section sets some variables in a CFScript block. The first one is FB_.corePath, which was set to blank in the previous section. In this code, the current circuit stored in aPath is added as a list element to FB_.corePath using / (forward slash) as a delimiter. This builds the directory path down to the target circuit, starting at the top directory. We’ll see more of FB_.corePath in just a second.

fusebox.isHomeCircuit

The next three lines set three API variables. We have already seen fusebox.isHomeCircuit in section 6. This code sets it to FALSE because the core file is no longer processing the home circuit. Why should it be set to FALSE every time through this list? Why not set it once because it will always be FALSE ?

fusebox.isHomeCircuit is repeatedly reset because it is a writeable variable. Although it is not recommended to do so, a developer might set it to TRUE in her code. Because it would be incorrect if this happened, the core file takes the extra step to make sure it is FALSE.

fusebox.currentPath and fusebox.rootPath

The next API variable that is set is a new one— fusebox.currentPath. This variable contains the path from the root circuit to the path that is currently processing the circuit, in directory notation, with a trailing slash. This variable is used just a few lines later to do the actual <cfinclude> of fbx_settings.cfm files, but it is also available to the developer in his own code.

When used in a fuse, fusebox.currentPath is extremely helpful to resolve the path to the current directory. Because of the way that the Fusebox framework operates, every fuse gets <cfinlude> d into the root of the application— wherever the fbx_fusebox31_CF50.cfm is running. This could cause problems if you have a directory structure like the one shown in Figure 4.1.

Figure 4.1. A common directory structure for images.


If you have a fuse in the “products” directory and want to show images from the “images” directory nested below it, the HTML would look like this:

<img src="images/glove1.jpg" width="250" height="250" alt="glove"> 

This would work fine in normal HTML, but in Fusebox, all requests go through the index.cfm in the web root. By the time your fuse with the <img> tag is finished processing, the browser thinks it is being run from the root. The Fusebox framework <cfinclude> d the fbx_switch.cfm file in the target circuit, which <cfinclude> d your fuse. The browser cannot find glove1.jpg in the Images directory below the root. The tag would have to be changed to read

<img src="catalog/products/images/glove1.jpg" width="250" height="250" alt="glove"> 

					  

All solved, right? Unfortunately, no. Remember that one of the major aims of Fusebox is to create completely removable, independent components. If a fuse hard codes the value of its location relative to the root of the application, some of that severability is lost. If the location of the products circuit changes, all the image tags in all the fuses have to be modified. What a pain!

The answer is to use the variable fusebox.currentPath to refer to the location of the current template to the root:

<img src="#fusebox.currentPath#images/glove1.jpg" width="250" height="250" alt="glove"> 

					  

The next variable set is a reverse of fusebox.currentPath. fusebox.rootPath creates a string of ../ (dot dot slash) up to the root of the application from the current template. It looks like this:

../../../

This variable allows any circuit, regardless of where it is in the directory tree, to access files in the root circuit. It can reuse fuses, such as fbx_savecontent.cfm, which are in the core directory, or it can allow you to reuse certain directories, such as a global images directory as opposed to an images directory for each circuit.

Each of these variables is set each time the loop repeats, and it contains the value of the current loop’s circuit mapping.

Call the Right File

After the API is created for the current circuit in the loop, the fbx_settings.cfm is almost ready to be included. Just to review, we are looking at the second part of section 9:

<cftry> 
  <cfif StructKeyExists(FB_.ReverseCircuitPath, fusebox.Circuits[fusebox.HomeCircuit] & "/" & FB_.CorePath)>  
    <cfset fusebox.thisCircuit=FB_.ReverseCircuitPath[fusebox.Circuits [fusebox.HomeCircuit] & "/" & FB_.CorePath] > 
    <cfif fusebox.thisCircuit EQ fusebox.TargetCircuit> 
      <cfset fusebox.IsTargetCircuit=TRUE> 
    <cfelse> 
      <cfset fusebox.IsTargetCircuit=FALSE> 
    </cfif> 
    <cfinclude template="#fusebox.currentPath#fbx_Settings.cfm"> 
  </cfif> 
  <cfcatch> 
    <cfif fusebox.suppressErrors> 
    <cfelse><cfrethrow></cfif> 
  </cfcatch> 
</cftry> 

					  

At the top of this code section, the core file runs a <cfif> to determine if this code block should be processed. The core looks up the currently executing circuit in the circuits structure to see whether it is defined. If it is defined, processing continues; otherwise, the rest of this section is skipped. (If you look carefully, you might notice that the lookup does not occur in the circuits structure. It happens in the FB_.reverseCircuitPath structure based on the current mapping. Looking up the circuit mapping in the reverse structure is functionally equivalent to looking up the circuit name in the circuits structure.)

This is our first time through the loop, so the <cfif> returns TRUE because the circuit catalog exists. (Remember that catalog is the first circuit in the path down to reviews from the root.) Now, the variable fusebox.thisCircuit is set to the name of the current circuit (“catalog”).

The next code is a <cfif> block; its purpose is pretty obvious. If the target circuit is the current circuit, the variable fusebox.isTargetCircuit is set to TRUE. Otherwise, the variable is set to FALSE. Now, in each fbx_settings.cfm, you can check the value of fusebox.isTargetCircuit to allow specific code to be run based on whether the fbx_settings.cfm is the target circuit. We will see more of this when we get into Part III of this book.

After all those API variables are set, the fbx_settings.cfm file for this circuit is <cfinclude> d. At this point, the Fusebox API looks like the one in Table 4.2.

Table 4.2. API Variable Values at Section 9
API Variable Value
fusebox.isHomeCircuit FALSE
fusebox.isTargetCircuit FALSE
fusebox.homeCircuit thirdwheel
fusebox.fuseaction read
fusebox.circuit reviews
fusebox.targetCircuit reviews
fusebox.thisCircuit catalog
fusebox.currentPath catalog/
fusebox.rootPath ../


So far, the Fusebox framework processed everything except your code—the stuff that does the work when a user requests a page. We have covered Fusebox framework through section 9 of the core file, including setting up the framework and all the request-specific processing of the settings files—in essence, setting up the application for the current request. Now, we will complete our investigation of the core file by running the fuseaction that is defined for the request in the correct circuit and applying the layout templates to the generated content. We like to think of the last part of the core file as “fuses and layouts.”

  • Creative Edge
  • Create BookmarkCreate Bookmark
  • Create Note or TagCreate Note or Tag
  • PrintPrint