Just to be complete...
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=657
/JK
2009/10/27 Ryan Lubke <Ryan.Lubke_at_sun.com>:
> On 10/25/09 10:57 AM, Jan-Kees van Andel wrote:
>>
>> Hey (CC MyFaces Dev),
>>
>> For MyFaces, I have implemented the first version of Bean Validation
>> support. But my implementation had a TCK issue, because I had some
>> non-specified public fields. These fields indicated the runtime
>> availability of some libraries.
>> See: http://issues.apache.org/jira/browse/MYFACES-2386 for the issue.
>>
>> To fix it, I've moved the public fields to a separate, package-private
>> class (still in the API), to hide them from end users and fix TCK
>> issues.
>> But the problem with this solution is that the fields are used in more
>> than one package (currently "validate" and "component". Probably more
>> to come), giving me only one option: Code duplication.
>>
>> I personally hate code duplication, which leads me to the question: Is
>> it a good idea to put an API in the spec which contains the
>> information I'm providing in my current class?
>>
>> Initially I wrote this message because I hate code duplication, but
>> there might be another benefit, since 3th party libraries may also
>> want to check the existence of certain libraries. Especially Bean
>> Validation and Web Beans may have impact on framework/component
>> authors. I think some API like this is quite important, because JSF
>> (since 2.0) doesn't live on its own anymore, but interacts with other
>> libraries as well.
>>
>> My implementation
>>
>> (http://svn.apache.org/viewvc/myfaces/core/trunk/api/src/main/java/javax/faces/validator/_ExternalSpecifications.java?revision=829526&view=markup)
>> currently works for MyFaces, but the official API may need to be a bit
>> more reusable/extensible.
>> I was thinking of something simple:
>> public interface FacesEnvironment /* This name probably sucks */ {
>> public boolean isBeanValidationAvailable();
>> public boolean isUnifiedELAvailable();
>> // ...
>> }
>>
>> An interface might be overkill, but the EG may work out the details. ;-)
>>
>
> Specifics such as interfaces aside, this seems like a useful concept. I
> would recommend
> logging an issue against the spec [1] for 2.1.
>
> [1] https://javaserverfaces-spec-public.dev.java.net
>>
>> What do you guys think? Useful addition for "JSF 2.1"?
>>
>> Regards,
>> Jan-Kees van Andel
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_javaserverfaces.dev.java.net
>> For additional commands, e-mail: dev-help_at_javaserverfaces.dev.java.net
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_javaserverfaces.dev.java.net
> For additional commands, e-mail: dev-help_at_javaserverfaces.dev.java.net
>
>