2012-02-17 16 views
0

私はクラスレベルのアノテーション制約を使用したいと思います。しかし、内部の制約を自動的に検証することはできません。このテクニックに検証グループを組み込むために、私は1つの部分を手助けしたいと思います。ネストされたJsr 303検証アノテーション

@ConstraintA({ 
    @ConstraintB(stuff), 
    @ConstraintB(stuff, groups=SomeGroup.class) 
}) 
public class Form{ 
} 

私は現在、このように制約をトリガしています。

if(constraint instanceof ConstraintB){ 
     new ConstraintBValidator().isValid(target, context); 
} 

しかしこれはobviously.Iが最終的AnnotationInvocationHandler.invoke()メソッドを呼び出してはisValidメソッドをトリガするためにリファクタリング、まだそれから少し道をイムます吸います。

私の問題は、すべてのConstraintBインスタンスがConstraintAに渡されることです。適切なグループを持つ人だけがConstraintAに渡されることを願っています。私はこの能力が疑わしいので、どうやってどのグループを引き金にする必要があるのか​​、どのグループを引き出すべきなのかを特定できますか?

デバッグでは、どのグループをトリガーするかを指定するオブジェクトは表示されません。

アイデア?

答えて

0

この種の検証を可能にするJSR 303仕様のパターンが見つかりました。親検証規則を実行しない反復パターンは、入れ子になった検証のみを実行します。これは非常に便利です。私のネストされたバリデーションルールは条件付きで他のプロパティ値に基づいているので、ネストされたjsr303アノテーションで条件付きバリデーションが可能です。

@Documented 
@Constraint(validatedBy = ZipCodeValidator.class) 
@Target({ METHOD, FIELD, ANNOTATION_TYPE, CONSTRUCTOR, PARAMETER }) 
@Retention(RUNTIME) 
public @interface ZipCode { 
String countryCode(); 
String message() default "{com.acme.constraint.ZipCode.message}"; 
Class<?>[] groups() default {}; 
Class<? extends Payload>[] payload() default {}; 
/** 
* Defines several @ZipCode annotations on the same element 
* @see (@link ZipCode} 
*/ 
@Target({ METHOD, FIELD, ANNOTATION_TYPE, CONSTRUCTOR, PARAMETER }) 
@Retention(RUNTIME) 
@Documented 
@interface List { 
ZipCode[] value(); 
} 

私自身の検証がよりこのようなものです:

@RequiredIf ({ 
@RequiredIf(ifField="field1", matches={"true","somethingElse"}, requiredField="anotherField", andDisplay="error.code.msg"), 
@RequiredIf(ifField="field2", matches={"true","somethingElse"}, requiredField="anotherField", andDisplay="error.code.msg") 
    }) 
関連する問題