jsr372-experts@javaserverfaces-spec-public.java.net

[jsr372-experts] Re: Difference in UIInput#processValidators() in Mojarra and MyFaces

From: Kito Mann <kito.mann_at_virtua.com>
Date: Fri, 30 Jan 2015 09:20:59 -0500

+1 (update do with MyFacds behavior)

On Friday, January 30, 2015, Bauke Scholtz <balusc_at_gmail.com> 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
> <javascript:_e(%7B%7D,'cvml','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
>> <javascript:_e(%7B%7D,'cvml','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
>>>>
>>>
>>
>

-- 
___
Kito D. Mann | @kito99 | Author, JSF in Action
Virtua, Inc. | http://www.virtua.com | JSF/Java EE training and consulting
http://www.JSFCentral.com | @jsfcentral
+1 203-998-0403
* Listen to the Enterprise Java Newscast: *http://
<http://blogs.jsfcentral.com/JSFNewscast/>enterprisejavanews.com
<http://ww.enterprisejavanews.com>*
* JSFCentral Interviews Podcast:
http://www.jsfcentral.com/resources/jsfcentralpodcasts/
* Sign up for the JSFCentral Newsletter: http://oi.vresp.com/?fid=ac048d0e17