Yep, it was just the wordings that confused me (maybe because I'm not a native English speaker). I'm almost finished now. It's not that difficult once it's clear...
/Jan-Kees 2009/7/9 Gerhard Petracek <gerhard.petra...@gmail.com>: > the parameters you have to consider are: > 1) javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL > 2) javax.faces.VALIDATE_EMPTY_FIELDS > 3) javax.faces.validator.DISABLE_DEFAULT_BEAN_VALIDATOR > > *_PARAM_NAME are specific variable names of mojarra. > > anyway, the spec. is quite clear. > imo 2) just helps to avoid backward compatibility issues. > > regards, > gerhard > > http://www.irian.at > > Your JSF powerhouse - > JSF Consulting, Development and > Courses in English and German > > Professional Support for Apache MyFaces > > > > 2009/7/9 Matthias Wessendorf <mwessend...@gmail.com> >> >> >> Sent from my iPod. >> >> On 09.07.2009, at 21:26, Jan-Kees van Andel <jankeesvanan...@gmail.com> >> wrote: >> >>> Hmm, I'm getting closer. I misunderstood the indenting of the bullets >>> in the JavaDocs. The first bullet explains it. >>> >>> But the second bullet still looks silly (the part where >>> VALIDATE_EMPTY_FIELDS_PARAM_NAME is explained). >>> >>> It says something about the system being directed to validate empty >>> fields, and then it explains what to do with >>> VALIDATE_EMPTY_FIELDS_PARAM_NAME. These two sentences seem to be >>> telling the same thing. I suppose the second sentence is an in-depth >>> explanation of the first? >> >> Feel free to add better javadoc for myfaces ;) >> >>> >>> Regards, >>> Jan-Kees >>> >>> Ps. Is it allowed to quote JavaDocs on the mailinglist? That would >> >> I'd say so >> >>> make explaining problems easier, but I can remember a discussion about >>> copying JavaDocs to source code... :-) >> >> That is _totally_ different ;) >>> >>> >>> >>> 2009/7/9 Gerhard Petracek <gerhard.petra...@gmail.com>: >>>> >>>> hi jan-kees, >>>> >>>> jsf-validators (if present) are invoked in any case. >>>> that means: >>>> - bv is >not< available -> everything works as usual >>>> - bv is available -> a default validator gets added (see the new >>>> default-validator mechanism) which delegates to bv. >>>> >>>> regards, >>>> gerhard >>>> >>>> http://www.irian.at >>>> >>>> Your JSF powerhouse - >>>> JSF Consulting, Development and >>>> Courses in English and German >>>> >>>> Professional Support for Apache MyFaces >>>> >>>> >>>> 2009/7/9 Jan-Kees van Andel <jankeesvanan...@gmail.com> >>>>> >>>>> Hey, >>>>> >>>>> I'm currently implementing the JSF 2.0 changes in >>>>> UIInput.validateValue() for MyFaces, but the descriptions in the spec >>>>> seem odd. >>>>> >>>>> When I'm reading the PDF, it says that when Bean Validation is >>>>> enabled, during the RENDER RESPONSE phase, every UIInput gets a >>>>> javax.faces.Bean Validator attached to it. >>>>> Then, on the other hand, when I read the JavaDocs for >>>>> UIInput.validateValue(), I see the validation process with regards to >>>>> Bean Validation. >>>>> >>>>> The second step (described by the JavaDocs for validateValue) don't >>>>> make much sense to me. The way I understand it, there are two issues >>>>> with the described approach: >>>>> >>>>> 1 Duplication, since Bean Validators are only attached components when >>>>> Bean Validation is present. The validateValue method can piggyback on >>>>> this fact and just follow the old mechanism. >>>>> >>>>> 2 Backwards compatibility when Bean Validation is not present in the >>>>> container. In the JavaDocs for validateValue, I don't see that >>>>> "normal" Validators are called when Bean Validation is not present in >>>>> the container or when it it explicitly turned off. >>>>> >>>>> Is this an error in the spec or am I reading it the wrong way? What's >>>>> your opinion? >>>>> >>>>> Regards, >>>>> Jan-Kees >>>> >>>> > >
