Parameter 1 Of Function SetVariable, Which Is Now FORM., Must Be A Syntactically Valid Variable Name
Posted December 23, 2008 at 9:53 AM by Ben Nadel
Do you ever just have an error that is a pain to debug and once you debug it, you feel like total loser for even letting it be an error in the first place? Yeah, well that happened to me yesterday. I was updating a page when I started to get this ColdFusion error:
Parameter 1 of function SetVariable, which is now FORM., must be a syntactically valid variable name.
Now, normally, an error like this would be accompanied by a bunch of other information; however, since I was working remotely using Dreamweaver (don't get me started), the site I was editing did not have robust error reporting turned on. As such, I only got the above text with no template or line information.
Without the additional debugging information, I started to look for code based on the given error; I started to look for SetVariable() method calls. There were none! So, the next thing I started to do was comment out sections of the code and then re-running the page. After about 5 minutes, I narrowed it down to this line of code:
- <cfparam name="FORM." type="string" default="" />
Oops! Looks like I was copy-n-pasting a bunch of new CFParam tags and forgot to fill in the last one.
First, this is a poor error. It should probably have told me that the NAME attribute of ColdFusion's CFParam tag was not a syntactically valid variable name; that would have been much more meaningful. But, aside from that, the error itself is really interesting because it gives us some insight into how the CFParam tag might work. If I had to hazard a guess, I would say it looks something like this:
- <cfif NOT IsDefined( "CALLER.#ATTRIBUTES.Name#" )>
-
- <cfset SetVariable(
- "CALLER.#ATTRIBUTES.Name#",
- ATTRIBUTES.Default
- ) />
-
- </cfif>
Of course, the ColdFusion CFParam tag does type validation as well, so that would have to be in there; but I am just guessing based on the fact that this is throwing a SetVariable() error. It looks like they need better type checking on the Name attribute.
Reader Comments
I always enjoy trying to find the error when there is a missing closing cfif tag. CF gets really confused and states that there is a missing cfoutput, or some such other thing (even with line numbers that don't have anything to do with the cfif). I usually end up cfaborting sections of the page until I narrow down the error :)
@Gareth,
Yeah, missing tags can be tough. If I have a CFLoop that contains a CFIF, I sometimes end the CFLoop with a double CFIF :)
I also find trouble with tags that have closing tags, but at the same time do not require them. E.g:
<cftransaction /> can also be <cftransaction></cftransaction>
<cfinvoke /> can also be <cfinvoke></cfinvoke>
There are a few more tags like this. They work self-closed, or with a closing tag depending on the usage. Can be troubling sometimes! That's also ONE of the arguments I have FOR using the self-closing />. So that you can SEE straight away what its usage may be.
Anyone else agree?
Mikey :)
@Mikey,
I think 100% that self-closing tags should ALWAYS be used when applicable. Nothing boils my blood MORE than seeing this:
<cfmodule template="">
This is the *worst* when used as a Header / Footer include because I never know if is wraps content as in:
<cfmodule>
... content ....
</cfmodule>
... or is merely acting as an "include" until I can scroll down to the bottom and find the matching tag. Now, if the self-closing tag was used, it would be immediately evident if the tag wrapped tags!
Arrrrg! :)
