+1 but perhaps Mojarra could have a com.sun.faces context-param feature to re-enable the legacy functionality?
--
Neil Griffin
Liferay, Inc.
> On Jan 30, 2015, at 9:25 AM, Josh Juneau <juneau001_at_gmail.com> wrote:
>
> No objections...+1
>
> Josh Juneau
> juneau001_at_gmail.com <mailto:juneau001_at_gmail.com>
> http://jj-blogger.blogspot.com <http://jj-blogger.blogspot.com/>
> https://www.apress.com/index.php/author/author/view/id/1866 <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 <mailto:kito.mann_at_virtua.com>> wrote:
> +1 (update do with MyFacds behavior)
>
>
> On Friday, January 30, 2015, Bauke Scholtz <balusc_at_gmail.com <mailto: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 <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 <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 <http://www.virtua.com/> | JSF/Java EE training and consulting
> http://www.JSFCentral.com <http://www.jsfcentral.com/> | @jsfcentral
> +1 203-998-0403 <tel:%2B1%20203-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/ <http://www.jsfcentral.com/resources/jsfcentralpodcasts/>
> * Sign up for the JSFCentral Newsletter: http://oi.vresp.com/?fid=ac048d0e17 <http://oi.vresp.com/?fid=ac048d0e17>
>