Spec 1356 has been closed whereby the Mojarra way is chosen
(processValidators does first this, then children-and-facets). However,
today I stumbled upon
https://java.net/jira/browse/JAVASERVERFACES-2018 and
I see that exactly the other way round has been requested and "fixed" as
per 2.1.21.
This is confusing. Was issue 2018 unrightly closed as "fixed"?
Cheers, B
On Mon, Feb 2, 2015 at 4:27 PM, Brian Leathem <bleathem_at_gmail.com> wrote:
> +1 No objections.
>
> Brian Leathem
>
> On 2015-01-30 04:13 AM, Bauke Scholtz wrote:
>
> 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
>>>>
>>>
>>
>
>