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