LU> The reason is validate() calls
LU> setValue() internally. If a parent component is being validated, you
LU> expect that all your children has its values already set. if you call
LU> validate() before process the children, you cannot check the values of
LU> the children for validation, so it is useless.
I already guessed that. In hindsight, it makes indeed a lot more sense.
MR> So it appears to me that we have an opportunity here to align both
implementations and add a statement to the Javadoc so the behavior becomes
standard.
Certainly. I'd suggest to follow the MyFaces approach, if no one else
objects.
Cheers, B
On Fri, Jan 9, 2015 at 3:55 PM, manfred riem <manfred.riem_at_oracle.com>
wrote:
> Hi Bauke,
>
> It would be nice if both the implementation align on this.
>
> Looking at the Javadoc of UIInput (quoted below), it does not appear it is
> mandating an order.
>
> "In addition to the standard processValidators behavior inherited from
> UIComponentBase, calls validate() if the immediate property is false (which
> is the default); if the component is invalid afterwards, calls
> FacesContext.renderResponse(). If a RuntimeException is thrown during
> validation processing, calls FacesContext.renderResponse() and re-throw the
> exception."
>
> On the Javadoc UIComponent it appears that the pseudo code snippet is not
> stating what is done with the component itself. However on the prose before
> the component itself is mentioned:
>
> "Perform the component tree processing required by the Process Validations
> phase of the request processing lifecycle for all facets of this component,
> all children of this component, and this component itself, as follows."
>
> * If the rendered property of this UIComponent is false, skip further
> processing.
> * Call pushComponentToEL(javax.faces.context.FacesContext,
> javax.faces.component.UIComponent).
> * Call the processValidators() method of all facets and children of this
> UIComponent, in the order determined by a call to getFacetsAndChildren().
> * After returning from calling getFacetsAndChildren() call
> popComponentFromEL(javax.faces.context.FacesContext).
>
> So it appears to me that we have an opportunity here to align both
> implementations and add a statement to the Javadoc so the behavior becomes
> standard.
>
> Regards,
> Manfred
>
>
> On 1/8/15, 3:45 PM, Bauke Scholtz wrote:
>
>> 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
>>
>