Ok. I checked that once again - the problem is I need a way to find out in the decodeUIInput method if the component is disabled or readonly.
What I do not want is casting to all possible components - as soon as we would add a new one, we would have to change that. I could use reflection, that would be slower than just calling a method, though... Finally, I could stick a common interface on all the components which provide isDisabled and isReadonly. My problem now: those components are in the JSF API, and I guess I cannot just add an interface there without breaking the spec. How do you guys see that? regards, Martin On Sat, 22 Jan 2005 15:05:31 +0100, Martin Marinschek <[EMAIL PROTECTED]> wrote: > 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] > > > > > >
