Hi
I agree with MyFaces behavior. The reason is validate() calls
setValue() internally. If a parent component is being validated, you
expect that all your children has its values already set. if you call
validate() before process the children, you cannot check the values of
the children for validation, so it is useless.
As far as I can remember, the spec doesn't say anything about this.
Checking svn history, this detail has not changed since ancient times
(MyFaces 1.1.x).
regards,
Leonardo Uribe
2015-01-08 16:45 GMT-05:00 Bauke Scholtz <balusc_at_gmail.com>:
> Hi,
>
> While observing different behavior of composite components with a
> componentType extending UIInput, I noticed that the
> UIInput#processValidators() API is implemented differently in Mojarra and
> MyFaces.
>
> In Mojarra, the processValidators() is first executed on the UIInput
> component itself and then on its facets/children. But in MyFaces, the
> processValidators() is first executed on the UIInput component's
> facets/children and then on itself. Exactly the other way round.
>
> I've always designed my composites based on what Mojarra does, which feels
> more intuitive as it follows the component tree hierarchy (top-down
> approach), but they break in MyFaces. Who's correct here? Why exactly was
> one or the other approach chosen?
>
> Mojarra source code:
> http://grepcode.com/file/repo1.maven.org/maven2/org.glassfish/javax.faces/2.2.0/javax/faces/component/UIInput.java#UIInput.processValidators%28javax.faces.context.FacesContext%29
>
> MyFaces source code:
> http://grepcode.com/file/repo1.maven.org/maven2/org.apache.myfaces.core/myfaces-api/2.2.0/javax/faces/component/UIInput.java#UIInput.processDecodes%28javax.faces.context.FacesContext%29
>
> Cheers, Bauke