Sorry for reading that one so late, but the correct way (as far as the reference implementation has any saying in what is correct, and after checking that back with Manfred) is indeed to set the value to a a non-null value...
I have already implemented something to fix this in my local code-base, but I do still have a problem with readonly and disabled components - if the component is readonly or disabled, there should not be a value set; the problem is that I would need a common interface for the component where I can check the readonly and disabled attributes. I hope I will be able to commit a fix soon. regards, Martin On Fri, 21 Jan 2005 09:29:34 -0500, Sean Schofield <[EMAIL PROTECTED]> wrote: > Heath, > > I've been re-reading this thread. I think you have a point here. You > should definitely post this on the Sun forums. Most likely you will > get one of the spec people to write back. I've also gotten a response > when emailing feedback directly to the specgroup. I can't recall the > email address but there is an address on the web page with the latest > spec draft. > > Let us know what they say on that. I'd be curious to know the > reasoning even if they don't plan to change it. > > sean > > On Thu, 13 Jan 2005 13:41:56 -0600, Heath Borders > <[EMAIL PROTECTED]> wrote: > > 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] > > >
