]
ocpsoft commented on BVAL-41:
-----------------------------
Java naming conventions prefer "isBoolean()" and "hasBoolean()" ...
it would be nice if hibernate also supported these.
org.hibernate.validation.util.ReflectionHelper.containsMember(Class<?>, String)
...
try {
clazz.getMethod( "has" + property.substring( 0, 1 ).toUpperCase() +
property.substring( 1 ) );
return true;
}
catch ( NoSuchMethodException e ) {
// ignore
}
try {
clazz.getMethod( "is" + property.substring( 0, 1 ).toUpperCase() +
property.substring( 1 ) );
return true;
}
catch ( NoSuchMethodException e ) {
// ignore
}
...
Support BeanInfo implementation to receive property names
---------------------------------------------------------
Key: BVAL-41
URL:
http://opensource.atlassian.com/projects/hibernate/browse/BVAL-41
Project: Bean Validation
Issue Type: Improvement
Components: spec-general
Reporter: Emmanuel Bernard
Michael
- Why section 3.1.2 requires properties to follow the JavaBeans naming
convention? In many non-English speaking countries (and projects with
ridiculous managers/code standards), other prefixes are used and
proper BeanInfo implementations are supplied. Although it is not
pretty at all, since they are following the JavaBean spec, I don't
think Bean Validation shouldn't work out-of-the-box for them;
Emmanuel
I reused the Java Persistence wording actually and I explicitly reference
the Introspector class. Do people think we should be more cautious here?
Speaking for France, I've never seen a project bothering about get/is/set
and BeanInfo. People happily used frenglish: getCafeAuLait()
Actually I've never seen anybody from the server side bothering about
BeanInfos ;)
Michael
I've got an interesting case for that one: in some JVM languages,
another standard is used to represent properties. Let's take, for
instance, Scala.
In Scala, one could write a bean like:
@BeanInfo
class Person(var id : Long, var name : String, var surname : String)
Scala already maps vars as properties creating a private var, a public
getter method named like the var and a setter like var_=. Something
like:
private var _id : Long
def id = _id
def id_=(newId: Long) = _id = newId
that would translate to Java methods id and id_$eq (since = cannot be
used in method names). So, when one use @BeanInfo, a proper BeanInfo
subclass is generated by the compiler providing that mapping.
Given how popular JVM languages are getting, not following a spec in
another one and causing property support in those languages to fail to
work doesn't seem nice.
BTW, please let the JPA EG know about his as well.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: