click 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: My dump now lists both DOT and DOT.IN.NAME as different variables. Here's a couple of quotes from your original post: [quote][quote] >> This variable is not created as a structure as it SHOULD be.[/quote][/quote] This is incorrect. The variable created is URL["RFA.click"] not, URL.RFA.click. These are two DIFFERENT variables. [quote] > 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.[/quote] Well... err.. *no*, you don't. [quote] > 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.[/quote] 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 [allowsmilie] => 1 [showsignature] => 0 [ipaddress] => [iconid] => 0 [visible] => 1 [attach] => 0 [infraction] => 0 [reportthreadid] => 0 [isusenetpost] => 1 [msgid] => [ref] => [htmlstate] => on_nl2br [postusername] => Adam Cameron [ip] => adam_junk@hotma [isdeleted] => 0 [usergroupid] => [membergroupids] => [displaygroupid] => [password] => [passworddate] => [email] => [styleid] => [parentemail] => [homepage] => [icq] => [aim] => [yahoo] => [msn] => [skype] => [showvbcode] => [showbirthday] => [usertitle] => [customtitle] => [joindate] => [daysprune] => [lastvisit] => [lastactivity] => [lastpost] => [lastpostid] => [posts] => [reputation] => [reputationlevelid] => [timezoneoffset] => [pmpopup] => [avatarid] => [avatarrevision] => [profilepicrevision] => [sigpicrevision] => [options] => [akvbghsfs_optionsfield] => [birthday] => [birthday_search] => [maxposts] => [startofweek] => [referrerid] => [languageid] => [emailstamp] => [threadedmode] => [autosubscribe] => [pmtotal] => [pmunread] => [salt] => [ipoints] => [infractions] => [warnings] => [infractiongroupids] => [infractiongroupid] => [adminoptions] => [profilevisits] => [friendcount] => [friendreqcount] => [vmunreadcount] => [vmmoderatedcount] => [socgroupinvitecount] => [socgroupreqcount] => [pcunreadcount] => [pcmoderatedcount] => [gmmoderatedcount] => [assetposthash] => [fbuserid] => [fbjoindate] => [fbname] => [logintype] => [fbaccesstoken] => [newrepcount] => [vbseo_likes_in] => [vbseo_likes_out] => [vbseo_likes_unread] => [temp] => [field1] => [field2] => [field3] => [field4] => [field5] => [subfolders] => [pmfolders] => [buddylist] => [ignorelist] => [signature] => [searchprefs] => [rank] => [icontitle] => [iconpath] => [avatarpath] => [hascustomavatar] => 0 [avatardateline] => [avwidth] => [avheight] => [edit_userid] => [edit_username] => [edit_dateline] => [edit_reason] => [hashistory] => [pagetext_html] => [hasimages] => [signatureparsed] => [sighasimages] => [sigpic] => [sigpicdateline] => [sigpicwidth] => [sigpicheight] => [postcount] => 5 [islastshown] => 1 [isfirstshown] => [attachments] => [allattachments] => ) --> Structures from URL and FORM scope - Coldfusion - Advanced Techniques

Structures from URL and FORM scope - Coldfusion - Advanced Techniques

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 ...

  1. #1

    Default Structures from URL and FORM scope

    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 Guest

  2. #2

    Default Re: Structures from URL and FORM scope

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

  3. #3

    Default Re: Structures from URL and FORM scope

    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
    Adam Cameron Guest

  4. #4

    Default Re: Structures from URL and FORM scope

    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.

    Lupus 23 Guest

  5. #5

    Default Re: Structures from URL and FORM scope

    > 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
    Adam Cameron Guest

Similar Threads

  1. Sporadic loss of FORM scope data
    By kriskadela in forum Coldfusion - Getting Started
    Replies: 33
    Last Post: January 5th, 06:51 PM
  2. FORM scope and CFCs?
    By theShawn in forum Coldfusion - Advanced Techniques
    Replies: 5
    Last Post: July 20th, 04:12 PM
  3. faking a form scope
    By Ekimov in forum Coldfusion - Advanced Techniques
    Replies: 2
    Last Post: June 7th, 10:27 AM
  4. Array scope and a form
    By arlin411 in forum Macromedia ColdFusion
    Replies: 2
    Last Post: March 2nd, 05:08 PM
  5. Problem with sessions (in global scope vs class scope)
    By Yoyoma_2 in forum PHP Development
    Replies: 5
    Last Post: November 17th, 02:03 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •