Hi<br><br>The javadoc of Application.createComponent(FacesContext context, Resource componentResource) says this:<br><br>".....Call <a href="file:///D:/jdk-1_5_0-doc/jsf20/mojarra-2.0.3-SNAPSHOT/docs/javadocs/javax/faces/component/UIComponent.html#setRendererType%28java.lang.String%29"><code>UIComponent.setRendererType(java.lang.String)</code></a>
on the
<code>UIComponent</code> instance, passing
"<code>javax.faces.Composite</code>" as the argument........"<br><br>Now suppose a custom composite component extending from UIInput, but implementing NamingContainer/UniqueIdVendor. The component family in this case is "javax.faces.Input". The result is the component will not work because the renderer used for composite components assumes the family "javax.faces.NamingContainer". This is ok, because the user just need to register a custom renderer for its composite component under that family/rendererType like the spec says.<br>
<br>The problem is why it is mandatory to set "javax.faces.Composite" as renderer type. The javadoc should say:<br><br>"...If the renderer type is not set (return null), Call <a href="file:///D:/jdk-1_5_0-doc/jsf20/mojarra-2.0.3-SNAPSHOT/docs/javadocs/javax/faces/component/UIComponent.html#setRendererType%28java.lang.String%29"><code>UIComponent.setRendererType(java.lang.String)</code></a>
on the
<code>UIComponent</code> instance, passing
"<code>javax.faces.Composite</code>" as the argument...". In that case, a user can override the rendererType on the constructor and avoid this hack that works with the current spec:<br><br> public void setRendererType(String rendererType)<br>
{<br> //Ignore this call !<br> if (!"javax.faces.Composite".equals(rendererType))<br> {<br> super.setRendererType(rendererType);<br> }<br> }<br><br>Why override the default Renderer and use a custom one? Let's suppose the component proposed needs some custom code for converter, or for decode. The right place to put that kind of code is the Renderer class, not the component, but note it is possible to put that on the component class.<br>
<br>Does that sounds reasonable? should I create an issue for this one?<br><br>regards,<br><br>Leonardo Uribe<br><br>