This is a workaround, I agree, but very often putting a null value and validation on a field is used to make sure the user actually thinks about the field and enters something.
And I've had exactly this usecase recently... It's not too good an option to have to tell the client that this won't work just because of the framework not supporting it. regards, Martin On 12/30/05, Adam Winer <[EMAIL PROTECTED]> wrote: > On 12/29/05, Martin Marinschek <[EMAIL PROTECTED]> wrote: > > @default: I understand. > > > > @immediate: Why would that be? > > > > The general use-case for immediate UIInputs (as I have seen it > > proposed in books, and used it myself) has been a selectbox which > > triggers a form-submit. Depending on the value of the selectbox, some > > other section is disabled/enabled. > > OK. > > > Why can't that be model-based, and why shouldn't such an UIInput have > > a required value? > > I should back off a bit on "model-based": it's more that it shouldn't > have attached validation, basically because - as you've seen - it > doesn't really work well, 'cause then there's no way to have, say, a > Cancel button. > > My general development advice would be to avoid in any way possible > having immediate fields that trigger validation. For example, in your > selectbox example, you'd start it with a non-null value - and > enable or disable the corresponding section accordingly - so > "required" isn't needed. > > -- Adam > -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
