Hi,
Does anyone have objections on changing the spec to explicitly follow and
document the MyFaces approach? I.e. execute processValidators() on UIInput
children first and then on UIInput itself.
Cheers, B
On Fri, Jan 9, 2015 at 4:46 PM, Bauke Scholtz <balusc_at_gmail.com> wrote:
> 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
>>>
>>
>