Hi,
This only affects UIInput components wrapping other UIInput components like
some composite components. As far as I've observed, no one component
library has this as they usually just have their own custom renderers.
Moreover, they would otherwise have gotten complaints/bugreports on
different behavior when switching between Mojarra and MyFaces.
So I think that part is safe.
Cheers, B
On 20:12, Fri, Jan 30, 2015 manfred riem <manfred.riem_at_oracle.com> wrote:
> Hi all,
>
> As this is rather a fundamental thing that might impact library vendors I
> want them to weigh in on it.
>
> Andy, Brian, Catagay is there any impact you would expect from this?
>
> Note I am against introducing a context-param for this.
>
> If we decide that this needs to be the way forward I want this to be
> behavior you get when you opt-in to use 2.3.
>
> Thanks!
>
> Manfred
>
>
> On 1/30/15, 6: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
>>>>
>>>
>>
>