Hi Jan-Kees, thanks for creating this ticket. I'd like to see something like this. Sounds (to me) very useful...
-M On Tue, Oct 27, 2009 at 12:09 PM, Jan-Kees van Andel <jankeesvanan...@gmail.com> wrote: > Just to be complete... > > https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=657 > > /JK > > > 2009/10/27 Ryan Lubke <ryan.lu...@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-unsubscr...@javaserverfaces.dev.java.net >>> For additional commands, e-mail: dev-h...@javaserverfaces.dev.java.net >>> >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@javaserverfaces.dev.java.net >> For additional commands, e-mail: dev-h...@javaserverfaces.dev.java.net >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@javaserverfaces.dev.java.net > For additional commands, e-mail: dev-h...@javaserverfaces.dev.java.net > > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
