Structures from URL and FORM scope

[Lupus 23]

I've recently discovered an abborant behavior of CF MX. I vaguely remember
that this did not work this way in CF 5, but I could be mistaken. But check
this example.

I pass a URL variable called "RFA.click" with a value of "IOB.editDataForm".

This creates a variable in the URL scope called "RFA.click" with that value.

Now, if I param that like:
cfparam name="url.RFA.click" default="IOB.editForm"

The value of url.RFA.click will end up being IOB.editForm when it should have
been IOB.editDataForm

This is because using cfparam or cfset to create a variable name like
RFA.click will automatically create a structure called "RFA" with an key called
"click".

But, passing on the URL will create an element in the url struct called
"RFA.click".

This variable is not created as a structure as it SHOULD be.

Furthermore, if you do check for the existance of the struct "RFA", and then
create it in the same scope, you loose the origional URL scoped variable.

Clearly this is either a bug, or unexpected behavior. All variables in passed
scopes should be put to the same scrutiny that a set variable is.

What I am trying to accomplish is something like this.

I always copy all URL and FORM scoped variables to the request scope, and then
refer to them form there. I use 2 StructAppend statements to append the entire
URL and FORM scope to REQUEST in 2 lines of code.

I then put all my flow control variables into a structure nested in the
REQUEST structure called "RFA". The plan was to be able to overide these flow
control variables with ones passed in forms, or on URLs. It's seems to me that
this always worked back in CF 5 (maybe not)?

Some debugging samples:

CFDUMP of REQUEST:
action : iobUpdate.budgetSearch
cfdumpinited : TRUE
rfa : struct [empty]
rfa.click : iobUpdate.budgetDataEditForm

Request dump from debugging:
Request Parameters:
action=iobUpdate.budgetSearch
cfdumpinited=TRUE
date=02/28/2005
file_requested=index.cfm
rfa=Struct (45)
rfa.click=iobUpdate.budgetDataEditForm
sort_field=bud_no

See here how the rfa struct exists with 45 keys, but yet a variable called
rfa.click exists as well? The kicker is there is no way to refer to this
variable, any reference to RFA.anything looks in the structure.

Any ideas on a work around?

[Lupus 23]

I did some tests and was able to reproduce simular behavior on a CF 5 server.

[Adam Cameron]

Passing on the URL is doing the equivalent of this:

URL["dotted.variable.name"]

Dot notation assumes each element is substructure.

I can see how this might be confusing, but it doesn't seem anomolous to me.

--

Adam

[Lupus 23]

It doesn't seem anomolous to you that CFPARAM will set a value to an existing
variable?

Clearly request.RFA.click is defined, as shown by the request scope variable
dump. Or even in CFDUMP. But yet when a CFPARAM is performed against the same
name it sets the value assuming the variable is undefined.

I'm sorry but I'm having trouble following your logic.

Let's look at this one more time. Here is a CFDUMP of the REQUEST structure.
<cfdump var="#request#">
OUTPUT:
REQUEST:
rfa struct (45)
rfa.click iobUpdate.budgetDataEditForm

<cfif IsDefined("request.RFA.click")>
HERE IT IS<br>
<cfelse>
NOPE
</cfif>
OUTPUT:
NOPE

I would think that any time that IsDefined() returns false on a variable that
exists should be considered anomolous.

[Adam Cameron]

> It doesn't seem anomolous to you that CFPARAM will set a value to an existing

> variable?

Well, there's two things at work here:
1) you don't seem to understand that url["one.two"] is a different variable
from URL.one.two. They are.
2) What you're actually suggesting doesn't happen anyhow! (which surprised
me, to be honest)

Try this:

<!--- dsp.cfm --->
<a href="./act.cfm?dot.in.name=true">click</a>

<!--- act.cfm --->
<cfparam name="url.dot.in.name" default="false">
<cfdump var="#url#">

When I click on the link, I get told that URL["dot.in.name"] is TRUE. Not
FALSE.

If I ask whether isDefined("URL.dot.in.name"), I get yes.

If I extend this, as below, I still get predictable answers:

<!--- act.cfm --->
<cfparam name="url.dot.in.name" default="false">
<cfif not structKeyExists(URL, "dot")>
<cfset url.dot = structNew()>
</cfif>
<cfdump var="#url#">


My dump now lists both DOT and DOT.IN.NAME as different variables.

Here's a couple of quotes from your original post:

>> This variable is not created as a structure as it SHOULD be.

This is incorrect. The variable created is URL["RFA.click"] not,
URL.RFA.click. These are two DIFFERENT variables.

> Furthermore, if you do check for the existance of the struct "RFA", and then create it in the same scope, you loose the origional URL scoped variable.

Well... err.. *no*, you don't.

> Clearly this is either a bug, or unexpected behavior. All variables in passed scopes should be put to the same scrutiny that a set variable is.

Yes. But you have to understand that CF will aloow variables names to have
dots in them, but if so, one has to refer to them in struct["key.name"]
notation, not struct.key.name notation, as a dot in CF natively suggests a
substructure.

URL variables are handled by the webserver, not the CF server, so they
cannot know that ?foo.bar=true ought to be created as URL.foo.bar = true;
it just creates a variable called "foo.bar" in the URL scope, and gives it
value "true".

Same as if you say URL["key##name"]. This refers to a variable called
key#name in the URL struct. It does not refer to the "special meaning" of
a pound-sign in CF, which would just result in your code breaking ;-)

Make sense?



--

Adam