Skip to main content
Known Participant
March 15, 2016
Answered

referencing dynamic field names

  • March 15, 2016
  • 1 reply
  • 1145 views

I'm having an issue testing a form field for a null condition.  The field names on the form are created dynamically as the form is created based on a query that returns a list of documents uploaded by a user. Each row will contain the document ID, document title and file name. As I loop through the query I create the form field name for each row by attaching the document ID to a string. Here is the code that creates the form:

<cfform action="ec_process_attachment_upld.cfm"  method="post" enctype="multipart/form-data">  

<cfoutput>

<cfif #get_attachment_list.RecordCount# GT 0>

       <table border="1">

       <cfloop query="get_attachment_list">

             <cfset f_name = "upld_attachment_file" & #attachment_id#>

             <tr>

                    <td>#attachment_name#</td>

           <td><input type="file" name="#f_name#" value=""></td>

           <td>Delete</td>

       </tr>

       </cfloop>

       </table>

</cfif>

</cfoutput>


So, the field names generated will be upld_attachment_file1, upld_attachment_file2, etc.

Here is the code that does the processing of the form:

<cfloop query="get_attachment_info" >         

       <cfset f_name = "upld_attachment_file" & #attachment_id#>

       <cfset t_var = "form." & "#f_name#">

                   

       <cfif len(#t_var#) GT 0>

             Do stuff

       </cfif>

  </cfloop>

The query here is the same and the one that created form. As I loop through it, I'm again creating the field name on the fly. The problem comes in the CFIF statement when I try to test to see if the field is null or not. The test ends up testing the variable that hold the form field name rather than the form field itself. How can I test the form field?

Thanks

DW

    This topic has been closed for replies.
    Correct answer WolfShade

    Hi, dwright65‌,

    First of all, I'd like to point out that using hashmarks around variable names when not being directly output or not contained within strings can be detrimental - it actually might slow things down.

    <cfset f_name = "upld_attachment_file" & #attachment_id#>  should be <cfset f_name = "upld_attachment_file" & attachment_id />

    The best way to parse dynamic variable names is by using bracket notation.

    <cfif len(trim(form["upld_attachment_file#attachment_id#"]))><!--- You don't actually have to compare it to zero.  If the length is zero, it is false; if it's greater than zero, it's true --->

      DO STUFF

    </cfif>

    In this second code sample, the hashmarks are required because the variable falls within a string.  It could also be written as

    <cfif len(trim(form["upld_attachment_file" & attachment_id]))>

    HTH,

    ^_^

    1 reply

    WolfShade
    WolfShadeCorrect answer
    Legend
    March 15, 2016

    Hi, dwright65‌,

    First of all, I'd like to point out that using hashmarks around variable names when not being directly output or not contained within strings can be detrimental - it actually might slow things down.

    <cfset f_name = "upld_attachment_file" & #attachment_id#>  should be <cfset f_name = "upld_attachment_file" & attachment_id />

    The best way to parse dynamic variable names is by using bracket notation.

    <cfif len(trim(form["upld_attachment_file#attachment_id#"]))><!--- You don't actually have to compare it to zero.  If the length is zero, it is false; if it's greater than zero, it's true --->

      DO STUFF

    </cfif>

    In this second code sample, the hashmarks are required because the variable falls within a string.  It could also be written as

    <cfif len(trim(form["upld_attachment_file" & attachment_id]))>

    HTH,

    ^_^

    dwright65Author
    Known Participant
    March 15, 2016

    Thanks! that worked like a charm. I also found that I could use the Evaluate function, but everything I read said not to use it unless absolutely necessary.

    Dave Ferguson
    Participating Frequently
    March 15, 2016

    You should never need to use evaluate.  Using the bracket notation as described by WolfShade‌  will work just fine in almost all conditions.