Skip to main content
Inspiring
October 20, 2010
Question

Problem with form.FieldNames

  • October 20, 2010
  • 4 replies
  • 6795 views

I have a problem with a form.

The form has an action page. At the top of that page is the following code:

<cfif NOT #IsDefined("form.FieldNames")#>
    <cflocation addtoken="no" url="my form page">
</cfif>

All of the fields on my form page have default values. These values are kept in a session struct and get defaulted in application.cfm.On the action page, the session values then get updated according to what the user has entered on the form.The user then gets taken, via cflocation, to a page that shows what he/she has just entered, for verification purposes.

Straightforward. And many, many thousands of people have submitted the form without incident. But many others have submitted the form, only to be immediately returned to the form page with all values defaulted (as one would expect to happen if form.FieldNames is not defined).

Has anyone seen behavior like this? Can anyone suggest a solution?

Key facts:

1. The form definitely uses POST.

2. The form does not contain any fields whose names would cause a problem in form.FieldNames, eg. names ending in _required, _date, etc.

3. Version of CF is 7, running on Windows Server 2003 with 2G memory. JVM heap is 512M.

4. When this happens, the load is high (as I said -- many, many thousands of successful submissions occur).

5. This doesn't appear to be a browser issue.

Thanks in advance for any help.

This topic has been closed for replies.

4 replies

Inspiring
October 22, 2010

Sounds to me like some of your users might be losing session scope - especially since your data is being stored in session variables and only SOME of them are experiencing the problem.  Could be a problem with browser/cookie persistence or server P3P file?  It seems more likely that is probably the culprit than the Form.FieldNames not showing up.

Inspiring
October 23, 2010

insuractive wrote:

Sounds to me like some of your users might be losing session scope - especially since your data is being stored in session variables and only SOME of them are experiencing the problem.  Could be a problem with browser/cookie persistence or server P3P file?  It seems more likely that is probably the culprit than the Form.FieldNames not showing up.

True, the data gets stored in session variables. But if the session scope gets lost, all of those session variables get re-defaulted in the next page load, via application.cfm. The action page is testing for something (fieldnames) in the form scope -- they are two different scopes, correct? If the session scope is gone, the action page should still evaluate what the form is passing, and send me on to the next page, which will then show null values for all of the form fields passed. Only if form.fieldnames does not exist will it redirect me back to the initial page -- and that's what's happening for some users.

cfjedimaster
Inspiring
October 21, 2010

Ugh, must have been the email interface. Let's try this again:

>
> I assume you mean StructIsEmpty(form)? Yes, but again, the issue of *why* remains.

Isn't that what I typed?

And yeah - the why is mysterious. I'd see if you can find out a common
browser type.


> Are you saying that there might be cases where the form struct is NOT empty (and therefore could be looped over), but where its FieldNames key does not exist? In that situation, my technique fails but yours succeeds, and I'm eternally grateful. But if there are situations where the user can successfully submit the form and yet end up with a totally empty form struct, both techniques fail -- and I need to know the cause(es) of those situations.

I've seen that fairly recently:
http://www.coldfusionjedi.com/index.cfm/2010/10/15/Diagnosing-an-error--Form-entries-are-incomplete-or-invalid

Inspiring
October 21, 2010

You typed it, but it didn't show up either.

This is my first real lead!. Thanks; I'll post a followup once I've had a chance to investigate further.

Inspiring
October 20, 2010

I've seen something similar.  The user would properly submit the form and the page would process.  Then, with no input from the user, the page would reload with no form scope whatsoever.

Check your http logs to see if this is happening to you.  You might want to mail yourself the cgi scope, form scope, and timestamp before re-directing so you know where in the logs to look.

Legend
October 20, 2010

I rarely use form.fieldNames and never like this. Instead, I set a hidden form field like action="UPDATE" and then check this value:

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

...

<cfif form.action EQ "UPDATE">

     /* do whatever */

</cfif>

or as in your example:

<cfif form.action EQ "">
     <cflocation addtoken="no" url="my form page">
</cfif>

To go a little further, I also incorporate a fusebox technique to merge the URL and FORM scope into a single attributes scope:

/* usually in application.cfm or cfc */

<cfif NOT IsDefined("attributes")>

     <cfset attributes=StructNew() />

</cfif>

<cfif IsDefined("FORM")>

     <cfset StructAppend(attributes,FORM,false)>
</cfif>

<cfif IsDefined("URL")>

     <cfset StructAppend(attributes,URL,false)>
</cfif>

Then modify the original to:

<cfparam name="attributes.action" default="" />

...

<cfif attributes.action EQ "UPDATE">

     /* do whatever */

</cfif>

The reason I do it this way is that then it is easy to add simple links for DELETE or CREATE:

<a href="myFormActionPage.cfm?action=DELETE&id=123">Delete this entry</a>

<a href="myFormActionPage.cfm?action=CREATE">Create a new entry</a>

Inspiring
October 21, 2010

This technique looks helpful but it won't really solve my issue. However that <cflocation> gets triggered, it produces a lot of resentment. The user has just taken the time to fill in the form -- and he/she then gets returned to it with all entries gone and nothing processed. Successful processing of the form requires looping through form.FieldNames. The test is present only to prevent people from executing the action page directly.

I need to figure out why this is happening and deal with it. My only clue is that this issue occurs under high load, so my hunch is that this is memory-related. Are there reported problems with form.FieldNames in that situation? Is there a 'safer' (ie, more reliable) way for ColdFusion to process form entries?

cfjedimaster
Inspiring
October 21, 2010

While I'm not aware of any load issues in this regard, I normally use

this to check for an empty form:

and I normally use struct functions to loop through form fields

<cfloop item="key" collection="#form#"