[Hibernate-JIRA] Created: (HV-135) Constraints can contains constraint annotations to validate params before initialize is called
by Emmanuel Bernard (JIRA)
Constraints can contains constraint annotations to validate params before initialize is called
----------------------------------------------------------------------------------------------
Key: HV-135
URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-135
Project: Hibernate Validator
Issue Type: New Feature
Components: engine
Reporter: Emmanuel Bernard
not high priority
>From Sebastian Thomschke
--------------------------------------
I just had a look through the Hibernate Validator code, what struck me
was the way how you validate parameters. E.g.
private void validateParameters() {
if ( min < 0 ) {
throw new ValidationException( "The min parameter cannot be
negative." );
}
if ( max < 0 ) {
throw new ValidationException( "The max paramter cannot be
negative." );
}
if ( max < min ) {
throw new ValidationException( "The length cannot be
negative." );
}
}
I just had the idea, why don't we use the constraint annotations for the
built-in constraints themselves? E.g.
/**
* @return size the element must be higher or equal to
*/
@Min(0)
int min() default 0;
/**
* @return size the element must be lower or equal to
*/
@Min(0)
int max() default Integer.MAX_VALUE;
Then this kind of parameter validation could be done by the framework
and must not be repeated in every validator implementation.
What do you think?
Regards,
Seb
--------------------------------------
Emmanuel
Your idea is interesting. It could lead to infinite recursion if someone does not pay attention but could work.
I think it would better be a product feature though instead of a spec feature for this rev at least. We can't have "class" level constraints though as it conflicts with the composition model.
WDYT?
it seems to me that the ValidationException is wrong in the example you gave.
http://opensource.atlassian.com/projects/hibernate/browse/HV-134
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 10 months
[Hibernate-JIRA] Created: (HV-388) Support property level ScriptAssert
by jason shi (JIRA)
Support property level ScriptAssert
-----------------------------------
Key: HV-388
URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-388
Project: Hibernate Validator
Issue Type: New Feature
Components: engine
Affects Versions: 4.1.0.Final
Reporter: jason shi
Assignee: Hardy Ferentschik
Current hibernate validator's ScriptAssert can only defined on the Class level, not property level.
In OVal,it can define the ScriptAssert at the property level,eg:
{code}
public class BusinessObject
{
@NotNull
public String deliveryAddress;
@NotNull public String invoiceAddress;
// mailingAddress must either be the delivery address or the invoice address
@Assert(expr = "_value ==_this.deliveryAddress || _value == _this.invoiceAddress", lang = "groovy")
public String mailingAddress;
}
{code}
With property level,we can get following benefit:
1. Can be used in single property validation, It's very useful in UI layer validation
2. The validation rule is close to the property definition, it's easy to manage
In JSR303 spec, the ValueContext is not passed to the Contrain Validator as a parameter,
so the validator can't get the "Current Bean" of the current property to be validated.
The validation engine need to some special work to support this feature.
OVal can do this, so it won't be a problem for hibernate validator.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 10 months