0

私は JSR 303 BV の大ファンですが、現在のプロジェクトでは「コンテキスト依存の検証」が多く、BV でそれらを実装する合理的な方法が見つかりません。基本的に、検証ルールは以下に依存できます

  • ログインしたユーザー (http リクエストに保存されます)
  • 操作対象のユーザー - ユーザーの ID は /foo/bar/user/1/sth のような REST URL のパス パラメータです
  • これらの両方

ちょっとした例:

class Alphabet{
@Valid
private Alpha a;
@Valid
private Beta b;
@Valid
private Gamma g;
}

検証ルール: URL で提供される ID を持つユーザーがロール「admin」を持っている場合、「a」、「b」、「g」プロパティのいずれも null にすることはできません。ロールが「user」の場合、「a」のみが null であってはならず、他の props は null である必要があります。

したがって、基本的にこれらの種類のルールは、Alphabet クラスのクラス レベルの制約として簡単に実装できますが、カスタム バリデーターは URL で提供されるユーザーのアクセス ID を何らかの方法で必要とします。これを達成できるスマートな方法はありますか、またはすべての REST クライアントにユーザー ID を複数回渡すように強制する必要があります: URL とペイロードで、後者は BV によってのみ使用されます。より複雑なケースは、検証ルールがログインしているユーザーに依存する場合です。そのため、カスタム バリデーターは、ThreadLocal または HttpServletRequest から認証されたプリンシパルにアクセスする必要があります。

4

1 に答える 1

2

検証グループを利用できます：

//Define validation groups
interface AdminChecks {}
interface UserChecks {}

//Assign the constraints to the two groups
class Alphabet{

    @NotNull(groups={AdminChecks.class, UserChecks.class})
    private Alpha a;

    @NotNull(groups=AdminChecks.class)
    @Null(groups=UserChecksChecks.class)
    private Beta b;

    @NotNull(groups=AdminChecks.class)
    @Null(groups=UserChecksChecks.class)
    private Gamma g;
}

現在のユーザーの役割に応じて、バリデーターを呼び出すときに または のいずれAdminChecksかを指定しますUserChecks。たとえば、管理者チェックの場合は次のようになります。

Validator validator = ...;
Set<ConstraintViolation<Alphabet>> violations = validator.validate(
    new Alphabet(),
    AdminChecks.class
);
于 2013-03-04T07:56:55.440 に答える