I have to say that I totally disagree on explicit activation of 2.3
features via context parameters and such. Just make use of <faces-config
version="2.3"> for that as usual.
Cheers, B
On Thu, Dec 10, 2015 at 12:03 AM, Michael Müller <
michael.mueller_at_mueller-bruehl.de> wrote:
> IMHO Arjan is right when he mentiones a new tag does not need a switch to
> enable it.
> The user simply may omit the new tag...
>
> Herzliche Grüße - Best Regards,
>
> Michael Müller
>
> Read my books
> "Web Development with Java and JSF": https://leanpub.com/jsf
> "Java Lambdas und (parallel) Streams": https://leanpub.com/lambdas-de
>
>
> Am 09.12.2015 um 15:14 schrieb arjan tijms:
>
>> Hi,
>>
>> In JSF 2.3 multiple switches are present at the moment to enable 2.3
>> features. While some of them are understandable, others are more difficult
>> to understand.
>>
>> The one I find difficult to understand is this one:
>>
>> <context-param>
>>
>> <param-name>javax.faces.validator.ENABLE_VALIDATE_WHOLE_BEAN</param-name>
>> <param-value>true</param-value>
>> </context-param>
>>
>> This is to enable the new f:validateWholeBean tag.
>>
>> It's explicitly mentioned in the taglib doc:
>>
>>
>> <code>javax.faces.validator.BeanValidator.ENABLE_VALIDATE_WHOLE_BEAN_PARAM_NAME</code>.
>> If this parameter is not set, or is set to false, this tag
>> must be a no-op.
>>
>> Can someone help me understand why a new tag needs to be enabled? This
>> can't possibly clash with existing behavior, can it?
>>
>> Then there are 2 more general switches.
>>
>> As for the following methods:
>>
>> Application#createBehavior
>> Application#createConverter(String/Class)
>> Application#createValidator
>>
>> these depend on faces-config.xml's version being set to 2.3. If it's not
>> exact "2.3", they will not look for the corresponding artifacts with the
>> managed=true attribute set on their annotations. Since the existing (JSF
>> 2.2 and earlier) annotations did not have this attribute, I wonder why
>> this
>> switch is needed here.
>>
>> Then if that aren't enough switches, there's also the following:
>>
>> <context-param>
>> <param-name>javax.faces.ENABLE_CDI_RESOLVER_CHAIN</param-name>
>> <param-value>true</param-value>
>> </context-param>
>>
>> This on its turn makes sure that an exception is thrown when someone
>> attempts to inject any of the new injectable artefacts.
>>
>> E.g. without this setting, the following will throw at runtime:
>>
>> @Inject
>> @ApplicationMap
>> private Map<String, Object> applicationMap;
>>
>> Another use of this setting is that without it (or with value set to
>> false), the EL resolver for the implicit JSF 2.2 variables will use the
>> native resolver, otherwise the CDI EL resolver will be used.
>>
>> I think it might be better to have a JSF 2.3 be JSF 2.3 by default, and
>> then allow to selectively set certain features to their 2.2 behavior.
>>
>> Additionally, with the current setup the difference between
>> javax.faces.ENABLE_CDI_RESOLVER_CHAIN and the "2.3" in the
>> faces-config.xml
>> file to enabled different 2.3 features seems a bit arbitrary.
>>
>> Thoughts?
>>
>> Kind regards,
>> Arjan Tijms
>>
>>
>