What did you change?
On Sat, 22 Jan 2005 17:48:41 +0100, Martin Marinschek <[EMAIL PROTECTED]> wrote: > I hope the problem is fixed now... > > regards, > > Martin > > On Sat, 22 Jan 2005 17:31:15 +0100, Martin Marinschek > <[EMAIL PROTECTED]> wrote: > > This is exactly the problem I was trying to resolve; the validator was > > not validating empty values. The solution in the RI is using empty > > string values for components which do not post back; this is what I > > will be implementing as well. > > > > But in the decode function, empty string values should not be supplied > > for components which are disabled or readonly, and this is what I am > > trying to do now. > > > > regards, > > > > Martin > > > > On Sat, 22 Jan 2005 10:05:53 -0600, Heath Borders > > <[EMAIL PROTECTED]> wrote: > > > I don't have a problem with using getAttributes (reflection). > > > > > > The problem with disabled components is in the HTML spec, those > > > components that are disabled should never be sent in the request. > > > > > > I have a bigger issue with components that have a null submitted value > > > not having validators or required checked on them. We have a > > > workaround for this, but it isn't to spec. I really don't see the > > > benefit of skipping validation checking if the component is null. > > > > > > On Sat, 22 Jan 2005 15:38:33 +0100, Martin Marinschek > > > <[EMAIL PROTECTED]> wrote: > > > > 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] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > -Heath Borders-Wing > > > [EMAIL PROTECTED] > > > > > > > > > -- -Heath Borders-Wing [EMAIL PROTECTED]
