2014-02-17 7 views
3

Мне трудно верить, что я единственный, кто хочет это сделать, но я не могу найти никаких ссылок, чтобы помочь мне преодолеть препятствие. Использование Spring MVC и аннотацию на основе проверки (я использую Framework 4.0 и Java 1.7), рассмотрим простую иерархию классов, следующим образом:Spring MVC Проверка унаследованных классов

abstract class Foo { 

    @Size(max=10, message = "The name has to be 10 characters or less.") 
    private String name; 

    public String getName() { 
     return this.name; 
    } 

    public void setName(String name) { 
     this.name = name; 
    } 
} 

class Bar extends Foo { 

} 

class Bang extends Foo { 

} 

Если я ставлю имя в экземпляре либо баре или Bang, который превышает 10 символов, я получаю ошибку проверки, которую я ожидаю. Предположим, однако, что я все еще хочу, чтобы Bar и Bang были получены из абстрактного базового класса Foo, но я хочу, чтобы атрибут name дочерних классов имел разные оценки.

Как аннотировать бар и взрыва, так что Bar.name имеет максимальную длину, скажем, 12 символов, в то время как Bang.name имеет максимальную длину 8 символов?

Спасибо большое, Роб

+0

[схожий] (http://stackoverflow.com/questions/9067420/can-i-override-a-jsr-303-validation-annotation) – gadget

+0

я видел. Я попробовал «кумулятивную» вещь в переопределенном методе getter без проверки валидации в базовом классе. Случается, что проверки не происходит вообще. Я пробовал peppering @Valid в разных местах, и я до сих пор не могу заставить валидатор стрелять по переопределенному getter. Должен ли я устанавливать валидатор «@Size» в базовом классе, а затем ограничивать его дальше в расширенном классе? Как max = 1000 в базовом классе, а затем max = 12 на расширении, чтобы использовать «кумулятивный» характер проверки путем аннотации? – RobAllen

+0

Дело в том, что из-за этого кумулятивный характер переопределения невозможен с аннотациями JSR303. – gadget

ответ

1

Короткий ответ заключается в том, что в проверке бина невозможно отключить ограничения в суперклассах. Здесь есть запрос функции https://hibernate.atlassian.net/browse/BVAL-256, предлагающий введение аннотаций типа @OverrideConstraint или @IgnoreInheritedConstraint. На данный момент это невозможно сделать.

См. Также http://lists.jboss.org/pipermail/beanvalidation-dev/2012-January/000128.html и https://hibernate.atlassian.net/browse/HV-548.

1

Создать новое поле в производных классах и переопределить методы.

class Bar extends Foo { 
    @Size(max=12, message = "The name has to be 12 characters or less.") 
    private String name; 

    @Override 
    public String getName() { 
     return this.name; 
    } 

    @Override 
    public void setName(String name) { 
     this.name = name; 
    } 
} 
+0

Спасибо, но разве такое поражение не имеет целью иметь абстрактный базовый класс? – RobAllen

+0

Если вы используете только абстрактный класс для хранения поля 'name', да, это так. Если абстрактный класс содержит другие общие поля, методы и т. Д., То это может стоить того. –

+0

Я вижу вашу точку зрения. Исходя из моего упрощенного примера «Foo Bar Bang», это в основном абстрактный класс Person, который содержит все общие атрибуты, которые могут распространяться более конкретные типы людей. – RobAllen

1

вы можете поставить аннотацию @Size(max=12, message = "The name has to be 12 characters or less.") на метод геттера.

Так что просто переопределите поле имени и поместите свою персонализированную аннотацию на метод геттера. Он будет работать так же, как поставить аннотацию проверки на поле. смотри пример ниже:

class Bar extends Foo 
{ 
    @Override 
    @Size(max=12, message = "The name has to be 12 characters or less.") 
    public void getName(String name) 
     { 
      this.name = name; 
     } 
} 
Смежные вопросы