- From: Matthew Raymond <mattraymond@earthlink.net>
- Date: Tue, 25 Jul 2006 06:18:51 -0400
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?)
Received on Tuesday, 25 July 2006 03:18:51 UTC