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]
