Re: [whatwg] non-checked checkbox posting success?
On Mon, 24 Jul 2006, Ric Hardacre wrote: When using checkboxes in forms i find myself doing this input type=checkbox name=foo value=true input type=hidden name=foo value=false and retrieving the value from the posted form data a bit like this if( checkbox.value == false )then bSomeBool = false; else bSomeBool = true; Michel then pointed out that this is particularly important when you don't know which form controls were submitted. You can already do all this. Just use a type=hidden control to list the controls that were included: input type=checkbox name=foo input type=hidden name=present value=foo Then, check to see if present has the value foo (amongst others), and if it does, handle foo.checked. For cases where you have tables, and each row represents a record with multiple controls, just have one hidden control per row, indicating the row is present. This is better than a solution for checkboxes, because it works for other controls too, like selects, which might not submit a value, or disabled text controls, which wouldn't submit a value either. HTH, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] non-checked checkbox posting success?
On Mon, 24 Jul 2006 22:59:07 +0700, Ric Hardacre [EMAIL PROTECTED] wrote: When using checkboxes in forms i find myself doing this I don't see how this input type=checkbox name=foo value=true input type=hidden name=foo value=false if( checkbox.value == false )then bSomeBool = false; else bSomeBool = true; is in any way better than this input type=checkbox name=foo if (checkbox.value == checked) then bSomeBool = true; else bSomeBool = false; IMHO, the former example adds neither semantic depth nor programming convenience compared to the latter. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] non-checked checkbox posting success?
What I don't understand about this whole unchecked value issue is why this is even necessary. The status of a check box is a binary value. If no value is returned, the server can simply assume the unchecked value. In fact, the server could initially set a string to the unchecked value, then replace it with a checked value if one is returned. This has always been the case, and won't cause any real hardship if we continue to only allow a checked value for on to be sent to the server. By contrast, if we allow an unchecked value to be sent to the server, server software developers will have to deal with both nothing being sent AND a unchecked value being sent, because they will still have to support legacy clients. You might argue that Javascript can handle legacy browsers, but then you create a dependency on scripting while you still have to perform a more complicated form of server-side validation to avoid potential security problems. Remember, if only the checked value is returned, then the server-side code can test for its mere existence and use the resulting boolean value to determine whether to use the checked or unchecked string. Once you have a value returned for the unchecked state, you have to evaluate the string to determine the state of the control, rather than simply testing for its existence. (Actually, when you consider that server-side validation needs to be performed to ensure that improper values are not returned by a check box, one has to wonder why you'd even bother with allowing values other than on to be returned. Anyone have a scenario where the actual string returned is of any use?)
