tracker issue : CF-3041386

select a category, or use search below
(searches all categories and all time range)
Title:

Bug 82771:When CF handles a form post that contains N form fields of the same name, it combines them into a list

| View in Tracker

Status/Resolution/Reason: Closed/Fixed/

Reporter/Name(from Bugbase): Raymond Camden / Raymond Camden (Raymond Camden)

Created: 04/28/2010

Components: Language, Tags

Versions: 10.0

Failure Type: Unspecified

Found In Build/Fixed In Build: 0000 / 280762

Priority/Frequency: Normal / Unknown

Locale/System: English / Platforms All

Vote Count: 12

Problem:

When CF handles a form post that contains N form fields of the same name, it combines them into a list. So for example, if you had two form fields with the name, "name", the value of form.name is a list that combines the two values. However, imagine a user enters "Camden, Raymond" and "Smith, John" in those two fields. Now we have form.name="Camden,Raymond,Smith,John". There is no way to tell which value was in the first field and which was in the second.What we need is a way to tell CF to NOT use a list but an array instead. Perhaps a simple CFSETTING: <cfsetting treatmultipleformfieldsasarray="true">. This would then give me a non simple form.name value (an array). That's an ugly tag right there, but you get the idea. This would be backwards compatible.Now you may argue - why not just use different form names? Sometimes we don't have control over the form post. It may be a remote post for example. We can use Java to get around it, but if CF is already doing the work ("Hey, I see another form.name, I'll just listAppend it!") then it seems like it should be trivial for it to use an array if asked to ("Wow, another form.name? Well Ray said he wanted an array so I'll use that instead.")
Method:

Create a form with 2 (or more) fields of the same name. Use commas in your value. Now try to figure out which is which.
Result:

----------------------------- Additional Watson Details -----------------------------

Watson Bug ID:	3041386

Deployment Phase:	Release Candidate

External Customer Info:
External Company:  
External Customer Name: Raymond Camden
External Customer Email: 5FBC41E943BD265C992015D5
External Test Config: 04/28/2010

Attachments:

Comments:

This bug has been voted..
Vote by External U.
22191 | November 11, 2011 01:02:27 AM GMT
This bug has been voted..
Vote by External U.
22192 | November 11, 2011 01:02:29 AM GMT
This bug has been voted..
Vote by External U.
22193 | November 11, 2011 01:02:30 AM GMT
Yes it would be nice if it will be an option because I take advantage of the list option too many times.
Vote by External U.
22194 | November 11, 2011 01:02:32 AM GMT
+1 vote. Definitely a good idea. I've always thought that treating them like a list was a sub-optimal approach. -- Adam
Vote by External U.
22195 | November 11, 2011 01:02:33 AM GMT
This would be a great feature to add.
Vote by External U.
22196 | November 11, 2011 01:02:34 AM GMT
This seems a good approach to this issue. Note particularly that the originator points out that we sometimes have no control over the incoming form fields.
Vote by External U.
22197 | November 11, 2011 01:02:35 AM GMT
Has My Vote. Or you could specify a delimeter for the lists being received.
Vote by External U.
22198 | November 11, 2011 01:02:36 AM GMT
I would love to see this happen. I cannot think of any reason not to support it. I'd also wonder if it would make sense to offer it as an application setting too so that all form posts (or GET) within an application are handled this way
Vote by External U.
22199 | November 11, 2011 01:02:37 AM GMT
Ok I'll bite, though think cfsetting or more local tag is best place for. Global is dangerous in vary large mult-dev environments (gov't for example)
Vote by External U.
22200 | November 11, 2011 01:02:39 AM GMT
This bug has been voted..
Vote by External U.
22201 | November 11, 2011 01:02:40 AM GMT
This bug has been voted..
Vote by External U.
22202 | November 11, 2011 01:02:41 AM GMT