CF 3.x now allows you to directly reference values stored within a CFQUERY result set. To reference a value stored in query myquery in column mycolumn at row 4 requires the following syntax:

#Myquery.mycolumn[4]#

Steve Drucker President, Fig Leaf Software
sdrucker@figleaf.com

Taking Control of your Parameters
To increase performance of Cold Fusion applications and to write more readable, stable and portable code, it is best to include the applicable scope with each reference to a variable. But sometimes we don't know ahead of time whether a template is going to be called from a form or with a URL so we don't know whether to use Form.MyVariable or URL.MyVariable to obtain the value of MyVariable. I prefer to write code that, in a sense, "declares" variables near the top of each template by testing for the existence of a form or URL variable and then setting Variables.MyVariable to the value of what is found. Should neither a form nor a URL variable be found, I like to specify some alternate program flow, possibly using new code nested in a CFELSE tag, a CFLOCATION or CFINCLUDE tag.

The code for my "declarations" might look something like this:

<CFIF IsDefined("Form.MyVariable")>
 <CFSET Variables.MyVariable = Form.MyVariable>
<CFELSEIF IsDefined("URL.MyVariable")>
 <CFSET Variables.MyVariable = URL.MyVariable>
<CFELSE>
 <CFINCLUDE TEMPLATE="ParameterError.cfm?VariableMissing=MyVariable">
 <CFABORT>
</CFIF>

Once this code has run, we can refer to "Variables.MyVariable" without having to be concerned about whether the variable was posted from a form or appended to a URL. This becomes more important as the complexity of your code grows and you start using more CFINCLUDE tags.

You might be wondering why I don't just use a CFPARAM tag. There are some subtleties in how the CFPARAM tag works that prevent it from accomplishing all our objectives. Remember that we want to be able to set the value of Variables.MyVariable to the value of whatever was sent in, or possibly a default, so that we can refer to MyVariable explicitly within the Variables scope. CFPARAM does, indeed, set a default value to Variables.MyVariable if a variable called MyVariable is not found on either the URL or form that called the template. But what happens if you send in a URL or form variable called URL.MyVariable or Form.MyVariable and then try to reference Variables.MyVariable? CFPARAM does nothing at all if a Form or a URL variable of the specified name is sent in, so Variables.MyVariable goes undeclared and your template will crash when you try to reference Variables.MyVariable.

Perhaps in a future release of Cold Fusion, we will be able to declare all variables within the Variables scope in one clean little tag.

Erik Midtskogen Firm Support Software, Inc.
erik@firmsupport.com

Saving State by Passing Values Between Forms
1) On form submission, save all form fields into session variables

2) Use the JavaScript onChange event to save out form field contents into a hidden form contained within a hidden frame

3) Use the CF FORMFIELDS collection to dynamically replicate the form fields on each CFM page

Generally, I dont like to use session variables to hold a large amount of data, so option 1 is out. We've used options 2 and 3 successfully:

Option 2: Hidden Frame technique

Step 1: You need a frameset containing a hidden frame

<FRAMESET ROWS=*,0>
 <FRAME NAME=dataframe SRC=myform.cfm>
 <FRAME NAME=hiddenframe SRC=savestate.cfm>
</FRAMESET>

Step 2: The hidden frame should contain an HTML form containing hidden form fields for all the data to be submitted to CF for processing

<FORM ACTION=savedata.cfm METHOD=POST>
 <INPUT TYPE=hidden NAME=myfield VALUE=>
</FORM>

Step 3: Use the JavaScript onChange Event to write out changes to the form in the persistent hidden frame.

<FORM ACTION=page2.cfm >
<INPUT TYPE=text NAME=myfield SIZE=10 onChange=parent.hiddenframe.document.forms[0].myfield.value=this.value>
<INPUT TYPE=submit VALUE=Next Page>
</FORM>

Step 4: For final form submission to be written to the database, submit the HIDDEN form

<FORM>
 <INPUT TYPE=button onClick=parent.hiddenframe.document.forms[0].submit() VALUE=Write to DB>
</FORM>

Option 3: Dynamically replicate the form fields on each sub-form page
Cold Fusion supports a form element called FORMFIELDS. This form variable will contain a comma-delimited list of form elements passed to an action page. Using the CFLOOP tag, you can easily parse this list, outputting variables and their values into hidden form elements. This solution is more robust than the one previously described, could easily be turned into a custom tag and does not require JavaScript support.

<FORM ACTION=page3.cfm METHOD=POST>

 <CFLOOP LIST=#formfields# INDEX=iindex>
  <CFOUTPUT>
   <INPUT TYPE=hidden NAME=#iindex# VALUE=#evaluate(form. & iindex)#>
  </CFOUTPUT>
 </CFLOOP>
</FORM>

Steve Drucker
President, Fig Leaf Software
sdrucker@figleaf.com

JavaScript Read-Only Fields
Read-only fields only recently became part of the HTML 4.0 specification. You can, however, code this same level of functionality into your applications today by leveraging JavaScript events.

The JavaScript onFocus event executes javascript code whenever a user tabs into a form element. Its cousin, the onChange event fires whenever a user modifies the contents of a form field. Used together, these event handlers can render a field read-only such that only JavaScript program code may dynamically change the contents of a field. The example below works for text and password form input objects.

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">

<HTML>
<HEAD>
 <TITLE>Untitled</TITLE>

 <SCRIPT LANGUAGE="JavaScript">
  var savedval=""

  function myreadonlyfield(obj,mode) {

   if (mode==1) { /* onfocus event */
    savedval=obj.value
   } else {
    alert("This is a read-only field and may not be changed")
    obj.value=savedval
   } 

  }
 </SCRIPT>  

</HEAD>

<BODY>

<INPUT TYPE="text" NAME="myfield" onFocus="myreadonlyfield(this,1)" onChange="myreadonlyfield(this,2)" VALUE="5">
<INPUT TYPE="submit">

</BODY>
</HTML>

Steve Drucker
President, Fig Leaf Software
sdrucker@figleaf.com

One Form Please
When building data entry applications, it is almost always better to develop one HTML/CFML form for viewing, adding and editing records than it is to build separate forms for each function. Why? Because your application will be easier to maintain. Applications have a way of evolving over time. New fields get added, old fields get "retired" and so on. If you have to make a change to some aspect of your data entry application, it's better to have to change the code in only one template rather than having to go to two or three.

Leon Chalnick
President, Professional Presence Providers, Inc.
lchalnick@prprpr.com

Variables and Data Sources
Use a variable to name the data source(s) used in your applications. Instantiate this variable in your application.cfm file. If, for any reason, you need to be able to quickly and easily change the name of a datasource, it will be much easier to change it if you have to go to only one place.

Leon Chalnick
President, Professional Presence Providers, Inc.
lchalnick@prprpr.com

Stop Runaway Keys
When your application takes form submissions by writing the form data into a database which automatically generates unique keys, it's important that you do something to prevent the user from submitting the same form over and over. If you do nothing to prevent this, a user can submit a form full of data (creating a record into the database), hit his browser's Back button and submit the form again, thus creating a duplicate record. A relatively simple approach to dealing with this is to generate the unique key for the new record before the data entry form is displayed by your application. Store this unique key in a hidden field in the form. When the user submits the form, use a "select" query to see if the record already exists in the table. If it does, let the user know. If the record doesn't already exist, then it's safe to add it.

Leon Chalnick
President, Professional Presence Providers, Inc.
lchalnick@prprpr.com

Cryptic Killer
You only need to hear this horror story a few times before it really sinks in. You work for three months on a killer Cold Fusion application. You are about to bring it to your first potential buyer when you decide it may be safer to encrypt it first. You drop to a DOS prompt, encrypt your code and then realize that you encrypted your only copy.

If you decide to encrypt your Cold Fusion work, copy it to a different directory. Even better, copy it to a different machine. I make it a habit to only encrypt files from our network server on my personal machine's desktop.

Raymond Camden
morpheus@deathclock.com

Don't Mess with my Parameters
If your site uses URL variables, i.e., product_display.cfm?ProductID=5, always be careful to design your code to handle incorrect values for the URL variables, or the complete lack of those variables. For example, whenever I see a site that passes along information via the URL, the first thing I am tempted to do is screw around with those variables. In the example above, if this were my first time on the page product_display.cfm, I may completely strip out the ?ProductID=5 from the URL to see how the application handles it.

The same could be said for form variables as well, although it is much harder for a malicious visitor to screw around with those. For example, I may view the source on your search page and see that it's sending a few hidden form fields to configure the search engine. I could create a form on my server that calls your application but with my own values.