This content has been marked as final. Show 2 replies
The whole intention of that section seems to be to give an alternative to using a validator. Its the type of validation I tend to use to be honest since I find it the least cumbersome. I've hardly ever had any trouble with the extra phases happening.
gimbal2 wrote:I agree with you on this one.
The whole intention of that section seems to be to give an alternative to using a validator. Its the type of validation I tend to use to be honest since I find it the least cumbersome.
gimbal2 wrote:.. but .. isn't the whole point of PROCESS_VALIDATION lifecycle is to prevent updates to the model when the validation fails ... to skip straight to RENDER_RESPONSE ? I just don't see the point of having the validation failing ( by showing an error to the user ), and yet allowing the "illegal" value updated on the model / bean.
I've hardly ever had any trouble with the extra phases happening.
On a different matter ... I am still not sure how the JSR-303 validation fits in to the JSF lifecycle with regards to updating the model / bean. If you were using JSR-303 validations WITHOUT JSF, like so:
.. the bean would have been updated already with the "illegal" values for the JSR-303 validation to work / "detect" that validation fails. Now going back to JSR-303 with JSF, that would suggest that model gets updated before the validation takes place ( to mimic the non-JSF validation above ) ... but that can't be the case as nowhere in the JSF / J2EE documentation ( unless I missed it ) that says that UPDATE_MODEL takes place before PROCESS_VALIDATION only if JSR-303 is used. The JSF lifecycle diagrams always say PROCESS_VALIDATION takes place before UPDATE_MODEL, and only if validation succeeds.
ValidatorFactory factory = Validation.buildDefaultValidatorFactory(); Validator validator = factory.getValidator(); Set<ConstraintViolation<Bean>> constraintViolations = validator.validate(bean);
On the other hand, JBoss' <rich:graphValidator> is clearly documented so that it actually clones the bean and then updates the properties on the clone of the bean, not the bean itself. Hence, the bean must implement the Cloneable interface. ( http://docs.jboss.org/richfaces/4.2.X/4.2.2.Final/Component_Reference/en-US/html/chap-Component_Reference-Validation.html#sect-Component_Reference-Validation-richgraphValidator ). Okay, that link is saying that the use case for <rich:graphValidator> is for cross-field validation, but at least it documents that the model is not updated.