• Do not deploy CF Admin or sample applications to your production environment.
• Do not deploy RDS to a production environment. RDS is strictly for development, and should have no place in production whatsoever.

• Setup sandboxes in order to limit access to such CF system tags as CF_Execute and CF_Registry.
• Limit the database access of the user that drives your CF data sources to only what is needed.

• CF Admin has a "magic checkbox" to enable protection for all scopes. This will perform system regex checks against variable values flowing through CF to ensure no malicious code is present.
• Within your application.cfc, the line "this.ScriptProtected" enables protection on an application level as well.

• Store passwords as a hash rather than human text.
• Perform the actual authentication process via https/ssl
• Transmit session IDs via https/ssl
• Do not put session IDs into the url
• Use J2EE sessions

• Build in server side validation to ensure that submitted data is of the expected types
• use cfqueryparam to ensure that values submitted to queries are of the correct types
• put as much of your functionality into CFCs as possible, as the inherent use of CFARGUMENT will be yet another level of validation.
• Learn about and USE the CF function IsValid(). Do it. Do it.

The desert sun was just dipping behind the mountain when she began to
stir in the darkness of the rocky crevice she called home. While she
waited for the cool of night to finish falling upon her, she checked
the bundle of eggs packaged neatly in the back corner of her web-lined
cave. She pulled it close to herself, wrapping her legs around it and
turning it slightly within her grip, almost as if she were coddling it
like a baby.  A full week ago it was that she had spun the silken sac
and filled it with eggs, and any day now the little ones would be
emerging to take their first glimpse of the world. This was not the
first brood she had tended to; no, she had laid thousands of eggs in
her brief lifetime and sent many youngsters out into the harsh desert
to fend for themselves. But though this was but one of many egg sacs,
it was just as precious to her as any other, and she would protect it
with her life if need be.

The deepening shadows and cooling desert air roused her to the fact
that the web she had spun last evening was in need of repair if she
was to catch any supper. The violent grappling with a large Palmetto
bug the night before had left it quite disheveled and torn.

Cautiously she approached the door of her hideaway, her eight eyes
wide open as they always were, watching for any movement or change in
the dim light that would signal the presence of an enemy. Nothing
moved except for the wind, gently caressing the tiny hairs on her
glistening, black body and inviting her out into the night. With
perfect grace and dexterity she extended a long foreleg out into the
open, gripping the invisible web and pulling her round body forward.

In unison and amazing coordination her eight legs worked as she busily
inspected her web. In a few moments she knew what she had to do, and
began to run long strands of silken rope back and forth from the rocks
to the ground, over and under, until she was satisfied with the
unordered matrix that would ensnare her next meal.

In the moonlight the web glistened, as she made her way to the center
and hung herself upside down. She waited. She would wait all night
long without moving, if she had to, in order to feed. Hours passed.
The bright red hourglass pattern on her abdomen was beautiful in the
light of the traveling moon. She flexed her fangs in anticipation,
gently cleaning her legs one at a time as she awaited a passing
insect.

Another hour passed before she felt a small tug coming from one side
of her web. The tug grew in its intensity and frequency as she hastily
made her way down to where a male cricket had entangled his spiny legs
in her web. As she approached, she turned around and backed herself up
to the cricket, her long back legs working speedily and with
precision. Using first the right leg, then the left, she drew fresh
silk from her spinnerets and pulled it over the cricket like sticky
ropes of steel. In a moment she sensed that all hope of his escape was
gone, and turned to face him. Gripping him with her front legs, she
lowered herself until her fangs found the cricket's soft side, and
then she bit him. Letting the poison work, she turned again and drew
more silk over him, further ensuring that he would not escape. Another
bite, some more silk, and she climbed back up into her web, pulling
the paralyzed cricket behind her like a sack of potatoes. She secured
her supper so that it would not fall, and settled down for a much
needed meal. It was the crickets and Palmetto bugs and moths that
provided her with the nutrients she needed to produce sac after sac of
eggs. So many of her youngsters would not survive their first few days
in the world, and so by design her job in the world was to catch and
eat insects, and to bring young spiderlings into the world.

The sun began to light the landscape from behind the mountains on the
other side of the valley. Her meal complete, she dropped the cricket's
empty skeleton to the ground, and crawled back into the safety and
security of her silk and stone abode. She made her way again to the
corner where her egg sac was safely attached, listening to the faint
stir of spiderlings inside. Resting one motherly leg on the silky egg
case, and with her stomach full, she settled herself down to rest
until the darkness once more signaled her to the hunt.

If you’re churnin’ out a web app cause your sales guy said you would,

And the PM he’s a pushin’ cause he knows you’re just that good;

But the requirements call for nav that stretches to infinity,

Then it may be time to think about recursive hierarchy….

Oh, recursion is a big word to describe a special function

That can chase its tail and catch it if it’s written with some gumption!

You could rightly call it Schizo, as to why, here’s the scoop:

It will call itself AND ANSWER in a never ending loop!

The secret to its mental state that makes it strange, yet stable

Is the special way it uses scope to give its vars a label.

If a variable is private then it’s labeled V-A-R,

While the public ones are public with no label needed thar!

And so, oh best Beloved, this function’s prelude now is ended;

But I must insist that you press on to find it and befriend it!

For no programmer’s app is done, regardless of the version,

Unless it boasts, at least a mite, the power of Recursion!

A few quick comments about the fields. ParentID contains the id of the record that the item is a child of. Records with a parentID of zero are top level; they have no parents.

Okay, so storing the hierarchical data is no problem and the way we chose to do it is both elegant and makes perfect sense! The CHALLENGE, however, (there are no problems, only challenges) is how to retrieve and properly display this data while maintaining its hierarchical relationship. For our example, the requirement will be to retrieve the navigational data and output it using html Unordered Lists, maintaining the data’s hierarchy. Here is where the power of the recursive function is a perfect fit.

Recursion can be a difficult thing to visualize in action, so let’s first go through how one could retrieve and display this data if recursion did not exist.

First of all, we must know up front how many levels deep our data goes so that we know how many nestings to use in our code. In this case, none of the data goes more than 4 levels deep. Assuming our data has been retrieved into a query named qryNavigation, the following ColdFusion code will display our information as a properly nested unordered list:

Walking through this code, the first thing we have is a query containing all of the nav items. Step 1 is to create the opening UL tag for our unordered list. Next, we retrieve all of our top level (parentID = 0) nav items and loop through them. For each one, we check to see via a Query of Queries if that particular nav item has children. If so, we retrieve that items children and loop through those. For each of the children, we check to see if THEY have children. If so, we loop through them, repeating the process one more time. Opening and closing UL and LI tags are added appropriately to form a string containing a properly formatted html unordered list which is then output to the browser.

That is a lot of code, and as you can tell, it limits the data to 4 levels deep while our requirement called for infinite levels. Not the solution we’re looking for. We need one with a little more imagination, grace, elegance, and usability.

I’m just going to lay it on you; here is the equivalent recursive function that accomplishes the same thing, but without limitations and with less code:

Let’s walk through this recursive process. Step 1 really comes last, and that is our initial call to this function that kicks the whole process off like the first domino falling. From here on out, we will cease to use the actual value of the parent ID and simply refer to it as ‘X’; this will make it easier to walk through the code. We call the function passing a value of zero to the level argument (which lets us keep track of where we are in our recursive calls) and a value of X to the parentID argument (used when retrieving navigation subsets via query of queries). Our first call to the function sets up the two private (VAR scoped) variables for use by this instance of the function. Since we are at level zero, it then initializes the values of two public variables: navigation and menustring. Menustring is our cumulative variable, meaning that with every call to GenerateNav, we will be appending more and more items to it.

Our next step is to execute the query objNav which retrieves all items from the complete set of nav items that have a parentID of X. Once retrieved, we have our X level items and begin looping through them. For each item returned, we check to see if there are any children. If there are (drumroll please…), then we make a recursive call to GenerateNav, passing it a parentID equivalent to the current item’s ID, and a level equal to the current level plus one.

The recursive call to GenerateNav sets up its two private instances of checkForKids and objNav, skips the initialization of the public variables, then selects all nav items for the parentID that was just passed in. Those children are retrieved, we step through them, and for each of them that are found to have children themselves, we again call GenerateNav passing in the appropriate values for that particular instance of the function.

When we’ve gotten through every item in our first initial objNav query (which would have been all items with a parentID of zero), we add the closing UL tag to our public variable Menustring and then return it. Notice we enclose the code to add the closing UL tag and to return Menustring within a CFIF that looks at the level. This prevents Menustring from getting returned prematurely by any of our recursive calls.

When a recursive function calls another instance of itself, you can rightly picture that it just managed to perform mitosis and now has an identical brother performing the exact same work, only with its own private variables. Whatever variables were declared public are shared between the first and its brother, and any subsequent brothers that are spawned. As each clone completes its task, it disappears back into the ether until finally there is only the original instance left, and when it has completed its task, it returns the final value and itself disappears, completing the entire process. This is recursiveness in a nutshell. Beautiful, isn’t it?

You may also be wondering how useful it is to output your navigation in an unordered list. Bear in mind that I kept it as simple as possible and did not include fields to hold URLs and other linking information that would normally be present in a navigation table. Those can be added later and included within the information being appended to your Menustring variable, along with CSS class names based on level. Upon output, it is a relatively simple thing to create a Stylesheet to format your unordered list as a flyout menu (no javascript required), such as is shown here:

I hope you found this information both useful and inspiring, and will be looking for places to leverage it within your own application development. As the late great Buckminster Fuller once said, “…if the solution is not beautiful, then it is wrong.”, so let's keep it beautiful folks.

1. This code uses undocumented methods and is not supported by Adobe. It is not guaranteed to work against every version of ColdFusion server.
2. Most of the time, yours isn't the only site living on a particular host server. This tool will allow you to see and manage ALL mappings, whether yours or not, therefore you must be very careful not to delete someone else's mapping.
3. Performing your own back door mapping management without the admin's knowledge could get you kicked off of your current host.
   
4. Never drink and manage mappings at the same time.

THIS, VARIABLES, and VAR Scopes

These are three of the variable scopes that are found within the world of a ColdFusion object or component, and three scopes that can make you pull the rest of your hair out when you don’t know how to think about them. In a nutshell, you’re looking at three increasing levels of variable privacy, from most liberal to most private.

The “THIS” scope holds items that can be directly accessed from anywhere inside OR outside of the object itself. Consider the following example of an instantiation of the myTest.cfc that has a variable called THIS.GLOBALVAL within it’s INIT method:

The component code...

In this example, because the variable GlobalVal was put into the THIS scope within our object, our application could directly access it as a property. Cool, if that’s what you intended to happen. Not cool if it wasn’t.

The VARIABLES scope within a component object is a scope that can be accessed by any method within the object at any time, in real time. In other words, if our component had set up a variable called Variables.LimitedVal, all methods will be sharing that one instance of the variable. If method one sets it to “5”, and later the app calls method two which reads that variable, it will see the value “5”. Any attempt, however, from outside the object itself to manipulate that value will result in an error. The following would FAIL:

The component code...

And finally, the VAR scope. This scope is one which can be seen only from inside of the actual method itself. For example, I can have three methods, each that use a variable with the same name that was initialized within the VAR scope, and no method will ever see the variable used by the other methods. It is a VITAL thing that you initialize your private variables in the VAR scope inside of your methods, because by default they are set up in the VARIABLES scope, and who knows WHAT havoc will occur if you have methods sharing variables that were intended to be private. Consider the following sample of initializing a variable in the VAR scope:

Only the ‘sampleMethod’ method will be able to see and manipulate those variables set using the ‘var’ scope. VAR is so private, that every other method within our component could initialize variables with the same name within their own var scope and no overlap would occur.