tracker issue : CF-3560964

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

Multiple Form Elements With the same name turned into array - missing empty elements

| View in Tracker

Status/Resolution/Reason: Closed/Fixed/

Reporter/Name(from Bugbase): Michael Schmidt / Michael Schmidt (Michael.Schmidt.lmco)

Created: 05/15/2013

Components: General Server

Versions: 10.0

Failure Type: Non Functioning

Found In Build/Fixed In Build: Final / CF10_Update14

Priority/Frequency: Critical / All users will encounter

Locale/System: English / Win All

Vote Count: 16

Problem Description:
Prior to CF10 to turn a repeated form element into an array we used getPageContext().getRequest().getParameterMap().

This worked smoothly this feature was replaced in CF10 with the application flag: 
	<cfset This.sameFormFieldsAsArray = true>  This works nice except it removes empty elements.  getPageContext()...getParamterMap() now returns an empty struct.


Steps to Reproduce:
Create a form like so: <form method="post"><input type="fld" value='1'><input type="fld" value=""><input type="fld" value="3"><input type="submit"></form>

Actual Result:
This returns an array form["fld"] with a length of two containing [1,3]

Expected Result:
This should have returned an array form["fld"] = [1,"", 3]

Any Workarounds:
Switching the form to enctype="multipart/form-data" and using form.getPartsArray()

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

Watson Bug ID:	3560964

External Customer Info:
External Company:  
External Customer Name: Michael.Schmidt.lmco
External Customer Email:  
External Test Config: My Hardware and Environment details:

Attachments:

  1. May 16, 2013 00:00:00: 1_debugFormPost.cfm

Comments:

Please fix this. This bug makes this feature near useless. If you have 3 sets of form fields you can't reliably say that form.foo[2] was the 2nd foo element since it may have been the third.
Comment by External U.
15374 | December 04, 2013 09:46:35 PM GMT
See my note. This bug makes this feature - to me - 100% broken. If you have 3 sets of fields, you can't rely on form.foo[2] being the second foo element. It may have been the third but the user left the second blank.
Vote by External U.
15398 | December 04, 2013 09:47:17 PM GMT
It is useless now that it drops form data,
Vote by External U.
15399 | December 04, 2013 09:54:34 PM GMT
I 2nd the information provided. It is very common to expect the form values in the order provided to the user.
Vote by External U.
15400 | December 04, 2013 11:41:31 PM GMT
So you introduced a new BROKEN feature and remove a working feature that people relied on? C'mon this is just sloppy. Restore the old behavior and FIX the new feature.
Vote by External U.
15401 | December 05, 2013 12:14:00 AM GMT
Agree with Sean's wording. Pls just restore the previously working option. -- Adam
Vote by External U.
15402 | December 05, 2013 01:49:33 AM GMT
This bug has caught me out in the past. +1 to fix.
Vote by External U.
15403 | December 05, 2013 02:25:07 AM GMT
To be clear, I think there's two things that need addressing here: 1) restore getPageContext().getRequest().getParameterMap(); 2) if This.sameFormFieldsAsArray is true, make the form scope work as per expectation too. -- Adam
Comment by External U.
15375 | December 05, 2013 03:26:36 AM GMT
Yeah, that needs to be fixed, guys.
Vote by External U.
15404 | December 05, 2013 07:24:28 AM GMT
Definitely needs to be resolved immediately.
Vote by External U.
15405 | December 05, 2013 08:03:47 AM GMT
Please fix this issue ASAP! This is an important issue. Thx
Vote by External U.
15406 | December 05, 2013 09:46:33 AM GMT
This is marked as fixed, but I tested in the public beta 11 and it still isn''t fixed.
Comment by External U.
15376 | February 23, 2014 10:39:41 AM GMT
This issue is fixed, now getPageContext().getRequest().getParameterMap() returns an array retaining form elements with same name containing empty value as well.
Comment by Akhila K.
15377 | February 23, 2014 09:33:28 PM GMT
Eh? Are you saying that the fix is to *not* use the feature but to use getPageContext? That isn't a fix.
Comment by External U.
15378 | February 23, 2014 10:23:17 PM GMT
They fixed getParameterMap() by restoring the original behavior. Yay! They didn't fix the new-in-CF10 behavior that had replaced it (but didn't work the same way).
Comment by External U.
15379 | February 23, 2014 11:45:49 PM GMT
We didn't change the existing functionality of form scope when This.sameFormFieldsAsArray is true. That is because this will create inconsistency between array and comma separated representations of same form fields in FORM scope. Instead we have brought back getPageContext().getRequest().getParameterMap(). You should use that.
Comment by Himavanth R.
15380 | February 24, 2014 12:17:20 AM GMT
Himavanth.... no, no, no. This is *broken*. Please you have to understand that. You cannot consider this fixed. I've already run into people who assumed it would return blank fields and were surprised when it didn't.
Comment by External U.
15381 | February 24, 2014 05:48:51 AM GMT
It breaks the assumption that the form properly returns the empty elements in the array. In instances where you're using multiple sets of identical fields, you can not maintain a parallel loop to pull data.
Vote by External U.
15407 | February 24, 2014 10:45:38 AM GMT
Himavanth, I think you might be failing to understand WHY people would want to use "this.sameFormFieldsAsArray=true". It's generally not just because they want an array instead of a list, it's because **they want the blank fields included**. If blank fields aren't going to be included, then having "this.SameFormFieldsAsArray" is merely a shortcut to the old way of doing things: ListToArray(myForm.myMultiValueField). It's great that getPageContext().getRequest().getParameterMap() was fixed. But the this.sameFormFieldsAsArray should behave the same way.
Comment by External U.
15382 | February 24, 2014 11:08:39 AM GMT
I agree people might be using this setting as an alternative for getPageContext().getRequest().getParameterMap() But that must be because getPageContext()..... was not working in CF10. We had added sameFormFieldsAsArray for the bug #CF-3041386 which had a different usecase. (not empty strings) Form scope never used to give empty strings even in the list form. So it would be weird and inconsistent if list didn't give empty strings but array form did. Right? I agree marking this bug as fixed is confusing. I will change that.
Comment by Himavanth R.
15383 | February 25, 2014 06:42:58 AM GMT
Why would you say a form field shouldn't be empty? It is empty. That's it. See the *multiple* comments where if you have items 1, 2, and 3 and if the user leaves 2 blank, we can't tell that because the feature is collapsing the array.
Comment by External U.
15384 | February 25, 2014 06:47:51 AM GMT
When did i say that? All i said was about backward-compatibility and consistency. I agree there is a use case for empty strings. All i am saying is people should use getPageContext().getRequest().getParameterMap() from now.
Comment by Himavanth R.
15385 | February 25, 2014 06:56:34 AM GMT
You are right, I misread your statement, but this: "Form scope never used to give empty strings even in the list form." This. Is. Wrong. You are basically saying that because it was done wrong in the past we need to be backwards compat and consistent... with wrong behavior. This is a mistake. Heck - do this. Ask 10 CF devs about this new feature of saving form fields as an array and see how many assume - as I did - and others - that blank fields would be correctly represented as blank array items. We *must* stop the "it was this way in the past, right or wrong, and therefore we must match that" logic.
Comment by External U.
15386 | February 25, 2014 07:00:40 AM GMT
I agree completely w/Raymond here. The problem with always crying "backwards compatibility" is most people are under assumptions of the way the code. The assumption, and rightly so, is that empty form elements are returned as an empty array. I bet if you go ask all the people who implemented this, the vast majority have this assumption. So, the fact that it doesn't work, is going to lead to buggy code. I thought the whole purpose of this feature *was* to provide a way to track empty ignored elements. This line of thinking is what has everyone irritated about isValid("integer"). Just because it's broke in past versions, don't assume everyone knows it's broke is coding around the issue. They're not. You're making their code break by having functionality misbehave. Fixing this isn't breaking things, it's fixing people's code--code many probably don't realize is broken.
Comment by External U.
15387 | February 25, 2014 07:42:52 AM GMT
SeanACorfield expressed it best. Please fix.
Vote by External U.
15408 | February 25, 2014 12:07:43 PM GMT
It is my opinion that this bug is still not satisfactorily fixed. The new This.sameFormFieldsAsArray functionality will never be useful to anyone. The most common use case fails. Imagine you have three fields which have the same form names. Let's assume the user fails to enter something on the form correctly, and they have filled in the first and third element of the same named fields. If you are using This.sameFormFieldsAsArray, when you reload the page, to display the error messages, and highlight the items they need to correct, the user will now see the first and second fields of the same named items filled in. This is at best, confusing and disorienting to a user, at worst it can cause serious data integrity issues.
Vote by External U.
15409 | February 25, 2014 12:20:56 PM GMT
Agreed here. This is a bug and should be fixed.
Vote by External U.
15410 | February 25, 2014 12:33:56 PM GMT
Himavanth, I agree with you (to some extent) that array needs to be consistent with list, but I think the purpose of this feature was to work around the missing item in the list! Either way, the point is, both list and array are broken and they should be fixed. I don't see any backward compat issue here, because it was always broken and unusable. Believe me, no one is going to complain if you fix a broken feature. Asking to use getPageContext().getRequest().getParameterMap() is not really a solution. I don't think you can justify asking develops to use that instead of simply using the form scope. That's saying CF code is buggy, just dig into Java layer and use that code! If you strongly feel about keeping this behavior, I would at-least expect another setting to preserve null values in list and array. Lastly, please change the status accordingly. If you are not going to fix, you can certainly change it to "Won't fix" with appropriate reason.
Comment by External U.
15388 | February 26, 2014 12:18:48 AM GMT
Just adding my vote to get this fixed.
Vote by External U.
15411 | February 26, 2014 12:25:14 AM GMT
Some background: The problem with form scope not retaining the empty elements (when there are multiple elements with same name) was actually fixed once in CF6. But it was reverted due to lot of public feedback and bugs being logged. (Bugs # 33697, # 34340. These bugs are not available in the public bugtracker now. They were logged in the previous bug tracker.) This and the fact that people were always using getPageContext() if they needed the empty elements are the reasons we didn't want to fix this. But due to public feedback now, we have decided to sacrifice consistency for the sake of ease-of-use. If sameFormFieldsAsArray is set to true, the array in form scope will preserve empty elements. If it is false, the list will not preserve empty elements (for backward compatibility).
Comment by Himavanth R.
15389 | February 28, 2014 02:12:59 AM GMT
Nice one, cheers Himavanth. You couldn't share the discussions on those old bug tickets somewhere, could you? Am intrigued to see people's "logic". -- Adam
Comment by External U.
15390 | February 28, 2014 04:27:55 AM GMT
Thanks Himavanth!!
Comment by External U.
15391 | February 28, 2014 09:30:09 AM GMT
Can we expect this in the next update for 10?
Comment by External U.
15392 | February 28, 2014 09:36:07 AM GMT
Good point, Ray. This should be back-ported to 10 so as to fix the issue at source, and make sure there's no difference in behaviour bewteen 10 and 11. This will reduce chances of backwards compat issues arising if it's nipped at the bud as early as possible. -- Adam
Comment by External U.
15393 | February 28, 2014 09:40:29 AM GMT
Adobe, hello? -- Adam
Comment by External U.
15394 | March 09, 2014 01:59:03 PM GMT
Yes, we will make it available in the next update for CF 10.
Comment by Rupesh K.
15395 | March 10, 2014 03:50:35 AM GMT
It has been 3 or 4 updates since the post below from Rupesh Kumar was created and it has yet to be fixed in CF10. What is going on? Why post that if you do not intend to fix it!
Comment by External U.
15396 | September 22, 2014 08:21:55 AM GMT
Please get this fixed in CF10 asap!
Vote by External U.
15412 | September 22, 2014 08:22:25 AM GMT
@dabinaz, This looks like, it is fixed. Using the test code below, on CF10 update 14, I get an array with 4 elements, of which the third is an empty string. <!--- application.cfc ---> component { THIS.name = "TestSameFormFieldsAsArray"; this.sameFormFieldsAsArray = "true"; } <!--- test.cfm ---> <cfform name="test" id="myform" action="postfrm.cfm" method="post"> <cfinput name="fname" type="text" value="1"> <cfinput name="fname" type="text" value="ColdFusion"> <cfinput name="fname" type="text" value=""> <cfinput name="fname" type="text" value="p"> <cfinput name="postfrmbtn" type="submit"> </cfform> <!--- postfrm.cfm ---> <cfdump var=#form.fname#>
Comment by Piyush K.
15397 | November 26, 2014 05:06:53 AM GMT