it's not terribly uncommon to have a page that is expecting a particular variable, but the page may not know if that variable will be in the form scope or URL scope. case in point might be a resultset that does pagination. on the first submit, the variables would likely be in the form scope. as the user pages through the results, it's entirely possible that the variables would be in the URL scope.

the most straightforward way to handle this would be:

1. <cfparam value="myNewVar" default="" />
3. <cfif structKeyExists(URL, 'myVar')>
4. <cfset variables.myNewVar = URL.myVar />
5. </cfif>
6. <cfif structKeyExists(form, 'myVar')>
7. <cfset variables.myNewVar = form.myVar />
8. </cfif>

it checks both scopes for the var, and if it finds the variable in either, it assigns it to a new local variable. it's straightforward, but not particularly "clean".

the first place that i saw this handled more elegantly was in fusebox. fusebox takes both form and URL scopes and places any variables found there into the attributes scope. in the case of a collision (if a variable exists in both scopes), you can specify which one should take precedence. cleaner.

other frameworks take a similar approach. both model-glue and coldbox put form and URL vars into the event "scope".

so that's all well and good... but what if you're not using a framework? the question came up on cf-talk, and my answer was to use a custom tag that mimics the way fusebox does it. then 2 people (aaron rouse and dominic watson) demonstrated the most ridiculously simple/straightforward way to handle this. a definite headslap "duh charlie" moment. here's the code:

1. <cfset myAttributes = structNew() />
3. <cfset structAppend(myAttributes, URL) />
4. <cfset structAppend(myAttributes, form) />

that's it. no conditionals, no custom tags.

so... what's going on here?

as of coldfusion mx (6.0), all scopes are structures. so we first create a new empty structure. think of this as a container that we'll use to hold the data from both the form and URL scopes/structures. using the built in structAppend() function, we're simply adding URL and form variables into that container. now, in much the same way that fusebox uses the 'attributes' scope, and model-glue/coldbox use the 'event' scope, we can refer to the variables in the myAttributes 'scope', as it will contain data from both form and URL.

one thing to point out is that structAppend() takes an optional 3rd argument (overwriteFlag). by default, this is set to 'true'. so similar to way that the frameworks allow you to specify which scope should take precedence in the case that the same variable exists in both, the order in which you write your structAppends() is very important. if you want the URL scope to take priority, append the URL scope last. if you want the form scope to take priority, append the form scope last. whichever scope/struct is appended last will effectively overwrite the existing variable, giving that scope the "higher priority".