@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. Why can't that be model-based, and why shouldn't such an UIInput have a required value? regards, Martin On 12/29/05, Adam Winer <[EMAIL PROTECTED]> wrote: > On 12/28/05, Martin Marinschek <[EMAIL PROTECTED]> wrote: > > > af:subform has a "default" attribute which handles the > > > most common scenario where this comes up. > > > > I don't understand - "default" attribute? most common scenario? > > A subform is active if and only if some component inside of it queued > an event during Apply Request Values. > > *except* > > A subform w/default="true" is active if no other subform is active, or > if the other active subforms also have default="true". > > "default" defaults to false. > > This is enough to handle most scenarios I've encountered. > > > > That's "immediate", right? > > > > No, that's not immediate. Immediate on commands doesn't prevent > > validation for UIInputs which have themselves the immediate attribute > > set... > > Generally speaking, immediate shouldn't be used on a UIInput that > is going to have validation fire. The point of "immediate" in UIInput > land is for components that only affect the UI, and are not really > model-based, and these generally won't have validation rules. > > -- Adam > > > > > Well, ya could just download ADF Faces for now... :) > > > > > > > I can't bring in ADF Faces now - Open Source is precondition on this one... > > > > regards, > > > > Martin > > > -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
