No objections...+1
Josh Juneau
juneau001_at_gmail.com
http://jj-blogger.blogspot.com
https://www.apress.com/index.php/author/author/view/id/1866
On Fri, Jan 30, 2015 at 8:20 AM, Kito Mann <kito.mann_at_virtua.com> wrote:
> +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> 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
>>>>>
>>>>
>>>
>>
>
> --
> ___
>
> 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
>
>