> 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
