tags:

views:

98

answers:

3

Each time when using cfparam I have a kind of feeling that I put it in the wrong place or generally mis-using.

Consider this example, say we need to show the new entity form (with default input values):

<cfparam name="form.attachLink" default="" />
<input type="text" name="attachLink" value="#HTMLEditFormat(form.attachLink)#" />

Even this simple one makes me thinking about following questions on cfparam:

  1. Should I use it before exact usage place? Wont it break the Model/View idea?
  2. Or should I group them somewhere in model template, or maybe on top of the view?
  3. When paramin' the form data, maybe it's better to use StructKeyExists(form, "attachLink")? Sure, I do this (plus validation) when processing the submitted form, but for the fresh form this can be useful too -- for safety-paranoid people like me.
  4. Where else it makes sense to use this tag? I know one really useful place: custom tags, though they itself become more and more legacy too.

Thanks.

+2  A: 

At the risk of sounding unhelpful: "It depends."

I think it's a bit complicated by the fact that CFPARAM can be used for setting default values as well as validating the type of a variable and throwing an error when it doesn't match. That said, I almost always use it just for the former. With the latter, a lot of that has been subsumed by arguments to components.

One of the more useful uses is on the action page for a form with checkboxes.

<cfparam name="form.myCheckbox" default="" />

Since it's valid for none of the checkboxes to be checked on the form, this prevents me from having to create special validation to see if the form variable exists before using it and, since I'm almost always treating it as a list, an empty-string is still valid for list functions.

As for where to place them, when I use them I almost always put them at the top of the cfm file, but that's probably just a style thing. If you sprinkle them in your code I think you're going to run into cases where the variable is going to be set and you don't know where it happened.

Of course, I'm using Model-Glue pretty much exclusively these days. Not much use for CFPARAM.

Al Everett
I would second that I put them at the top. It keeps them all together in one place that is easy to find and debug if/when there are issues.
Jason
My company is not currently using any framework (against my wishes). When running a page that does DB updates/inserts, I generally block them at the top of the page. When using them to allow form re-display, as in the example above, I put them where they are in the example.
Ben Doom
A: 

If you are going to reference the variable in a form value, you should use cfparam with a reasonable default (even blank) to ensure that the variable exists. However, if the variable is only being referenced upon form processing, I would skip cfparam (unnecessary as you're not setting a value in the form) and instead use structKeyExists(scope, "key") in the form processing step.

In an MVC framework, you may have an option to set your default values in another manner. In this case, you are most likely not referencing the form scope directly, but rather a framework managed scope. Fusebox uses the 'event' scope. On page load, the Fusebox framework merges both the URL and FORM scope together into the EVENT scope. If you are concerned about 'breaking MVC', I recommend setting up, and/or testing for the necessary variables in your framework's scope (in my case EVENT) in the MVC controller (using your framework's recommended method) before you display the form in the view. Most likely you won't need cfparam for this.

Dan Sorensen
A: 

I think of cfparam the same way I think of variable declarations. I alway declare my variables as close as possible to where I'm going to use the variable. In coldfusion world, I use the cfparam tag right before the cfform tag.

It sounds like you're using an MVC framework. I don't see how this impacts the use of cfparam. The model is where you get the data. CFParam isn't specific to the model.

Brian Bolton