This behavior is what the W3C spec specifies. Here is my solution for components that don't have a value selected by default in HTML (therefor causing them not to put a name-value pair on the request):
Since we only process decodes on UIForms that were submitted (through the use of a hidden input), if the UISelectOne doesn't have a value, we can set its value to a blank String, which would then trip the required validator. Of course, this could trip up some converters, so it would probably be better to just leave the submitted value as null, but then that won't trip the required validator. Overall this means that a spec-change is in order. Do you guys agree? On Wed, 12 Jan 2005 15:25:15 -0600, Heath Borders <[EMAIL PROTECTED]> wrote: > This bug is appearing in a couple more places for me, and its starting > to be an annoyance. I don't want to just unilaterally make a solution > because I think IE is behaving according to the spec (I haven't > actually looked it up though). > > Basically, if you render an HtmlSelectOneRadio with a value that > doesn't correspond to any of the options, none of the are checked. If > you submit with none of the radios checked, nothing goes out on the > request. This means that we are setting the submittedValue to null > rather than to a blank String. This means that the required flag > doesn't ever get hit, and no validation errors will be reported. > > What do you think should be done? > > > On Mon, 3 Jan 2005 18:16:15 -0600, Heath Borders > <[EMAIL PROTECTED]> wrote: > > There is a bug in HtmlSelectOneRadio with requireds. Please check out > > my JIRA issue and let me know what you think. > > > > http://issues.apache.org/jira/browse/MYFACES-72 > > > > -- > > -Heath Borders-Wing > > [EMAIL PROTECTED] > > > > -- > -Heath Borders-Wing > [EMAIL PROTECTED] > -- -Heath Borders-Wing [EMAIL PROTECTED]
