Just to be complete... https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=657
/JK 2009/10/27 Ryan Lubke <[email protected]>: > 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: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
