Well, the problem with setting one of the radio buttons to checked if the value doesn't match any of the SelectItem values is that it goes agains the TLD spec.
So, one of the two would need to change. I really don't understand why they say to exit processing if getSubmittedValue() returns null. Do you know where I could post this question where spec people (or someone else more knowledgeable than me), could answer it? On Thu, 13 Jan 2005 14:38:22 -0500, Sean Schofield <[EMAIL PROTECTED]> wrote: > Yeah that makes sense. I thought about that after I sent my previous > reply. You would run into a problem with our friend "Mr. Disabled > Checkbox" The validator would complain that its required even if the > value was checked! > > In your specific radio button case, I don't think it makes sense to > have none of the options checked by default. Standard interface rules > would dictate an initial default value be checked. That is the whole > point of the radio button after all. If it was optional to have a > choice selected you could always use a checkbox. > > So in the radio case, I say fix your code so that there is a default > choice. We could also consider enforcing a default choice at the > component level. > > For other components like input text, I say provide a default value of > empty string (in the component not through the decode) if validation > is important. Actually, isn't there a "required" attribute? Maybe if > that is true, you could default the value to empty string (if none was > provided initially). > > Thoughts? > > sean > > > There is no way. From the API: > > > > "Retrieve the submitted value with getSubmittedValue(). If this > > returns null, exit without further processing. (This indicates that no > > value was submitted for this component.) " > > > > This means that if our UIInput's (which HtmlSelectOneRadio is) are to > > perform according to spec, they must return if getSubmittedValue() > > returns null. > > > > It will always return null if the HtmlSelectOneRadio doesn't have a > > value selected. > > So, the JSF lifecycle will silently allow a null-selection on > > HtmlSelectOneRadio, thus the required field doesn't work. > > > > > > On Thu, 13 Jan 2005 14:23:30 -0500, Sean Schofield > > <[EMAIL PROTECTED]> wrote: > > > > 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. > > > > > > I think the correct behavior would be to leave as null. If you change > > > to empty String this might have implications for the valueChangeEvent > > > (I use that one a ton.) > > > > > > I believe Struts handles this by changing to empty string as you > > > suggest. This causes headaches for me in detecting field changes. I > > > have my own system for detecting field changes (since Struts does not > > > have this) and I keep getting notified of changes that aren't really > > > changes. So then I have to go through the extra work of making sure > > > this is not just Struts changing things up on me. > > > > > > > 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. > > > > > > It seems odd that the validator won't be triggered when a null value > > > is submitted. Let me look into this and see if I can't come up with > > > something. If there is no way to get the validator to fire, then I > > > would say yes, a spec change would be in order. > > > > > > > -Heath Borders-Wing > > > > > > sean > > > > > > > > > -- > > -Heath Borders-Wing > > [EMAIL PROTECTED] > > > -- -Heath Borders-Wing [EMAIL PROTECTED]
