Hi
There are some examples where you really need to override the tag handler.
For example tomahawk t:dataTable :
<tag-name>dataTable</tag-name>
<component>
<component-type>org.apache.myfaces.HtmlDataTable</component-type>
<renderer-type>org.apache.myfaces.Table</renderer-type>
<handler-class>org.apache.myfaces.component.html.ext.HtmlDataTableTagHandler</handler-class>
</component>
The tag handler do some special internal processing. I'm sure there
are other components out there with similar behavior. The reason is
you usually need to add a couple of lines to process attributes with
MethodExpression instances. There is no other alternative.
EB>> On balance, I am inclined to take no additional spec action and fix the
EB>> impl bug mentioned in item 3. If the volunteer group has some
EB>> additional support to revert the change, I'm open to being convinced.
I have to say fix that (align the code with the xsd) will break a lot
of code (well as soon as the facelet-taglib is set to 2.2). The xsd
should be fixed instead.
regards,
Leonardo Uribe
2015-02-11 9:35 GMT-05:00 Edward Burns <edward.burns_at_oracle.com>:
> Hello Volunteers,
>
> An issue came into the Mojarra JIRA and I've had some friendly
> discussion with the reporter. When it became clear we did not agree I
> decided to give the issue an airing here.
>
> Here is some text from a corresponding spec issue that I created [1].
>
> EB> Part of the work for JAVASERVERFACES_SPEC_PUBLIC-599 includes this change:
>
> EB> The commit log message that made this change includes this text:
>
> EB> M jsf-api/doc/web-facelettaglibrary_2_2.xsd
>
> EB> Make it so a <tag> must have exactly one of <component-type>,
> EB> <resource-id>, or <handler-class>
>
> EB> Here is the rationale behind the above change: if you are going to
> EB> specify a handler-class, it does not matter what the component-type
> EB> is because the handler-class effectively can do whatever it wants to
> EB> create the component. The component-type is only necessary if you
> EB> want JSF to create the component for you.
>
> CT> Yes, I understand that you can do that, but here's why I feel this
> CT> should be reverted:
>
> CT> 1. Requiring the component's handler-class to create the
> CT> component-type couples them tightly together, removing the ability
> CT> to re-use a handler-class for other components. I feel this fights
> CT> against the original design, which encouraged the re-use of the 3
> CT> component parts: handler-class, component-type, and renderer-type.
>
> This was the original facelets design. The desired re-use was intended
> to be achieved using Java inheritance.
>
> CT> 2. The most typical use case of specifying a handler-class
> CT> for a custom component is to add MetaRuleset rules by overriding
> CT> createMetaRuleset(). In this case, delegating the creation of the
> CT> component to JSF is the desired functionality. Requiring every
> CT> custom handler-class to also create the component requires
> CT> developers to add unnecessary code.
>
> Of your three reasons, this one is the most compelling. What do others
> think here?
>
> CT> 3. The current implementation in
> CT> com.sun.faces.config.processor.FaceletTaglibConfigProcessor.java
> CT> simply doesn't match the xsd. Currently, any of the following
> CT> combinations can be defined in the taglib for a component:
>
> CT> handler-class (with optional component-type and/or renderer-type)
> CT> component-type (with optional renderer-type)
> CT> resource-id
>
> On balance, I am inclined to take no additional spec action and fix the
> impl bug mentioned in item 3. If the volunteer group has some
> additional support to revert the change, I'm open to being convinced.
>
> Thanks,
>
> Ed
>
> --
> | edward.burns_at_oracle.com | office: +1 407 458 0017
> | 18 days til DevNexus 2015
> | 28 days til JavaLand 2015
> | 38 days til CONFESS 2015
>
> [1] https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1362