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. ;-)
What do you guys think? Useful addition for "JSF 2.1"?
Regards,
Jan-Kees van Andel