Hi,
On Wed, Feb 11, 2015 at 8:50 PM, Leonardo Uribe <leonardo.uribe_at_irian.at> wrote:
> 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.
I hope this is not too much off topic here, but I always found exactly
this problematic. The handling of MethodExpressions is far from
optimal and those handler classes after do relatively simple things,
but make it hard to use a component depending on them with alternative
VDLs.
Kind regards,
Arjan
>
> 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