Условная проверка бинов

Я использую Bean Validation в своем проекте JSF. Теперь я столкнулся с ситуацией, в которой я хотел бы проверять метод ТОЛЬКО при проверке предыдущего метода.

Я приведу пример:

@AssertTrue(message="{invalidCode}")
private boolean isValidActivationCode() { ... }

if(isValidActivationCode()) {
    @AssertTrue(message="{alreadyActivated}")
    private boolean isAlreadyActivated() { ... }
}

Поскольку я получу код активации для каждого параметра, я хотел бы сначала проверить его. Если он недействителен, это приведет к нарушению. Если так, я даже не могу проверить, активирован ли он уже (так как код недействителен). Итак, возможно ли достичь чего-то подобного вышеупомянутому (функция оператора if, я знаю, это не сработает, но показывает, чего я пытаюсь достичь).

заранее спасибо

Обновить

Обход, как Рави К, упоминается:

@AssertTrue(message="{invalidCode}")
private boolean isValidActivationCode() { ... }

@AssertTrue(message="{alreadyActivated}")
private boolean isAlreadyActivated() { return isValidActivationCode() ? ... : true; }

Хотя мне интересно, есть ли чистый способ решить эту проблему? Если никто не даст ответ в ближайшее время, я буду считать, что для этого нет чистого решения, и я приму решение от Ravi K в качестве ответа на эту проблему.

Ответы на вопрос(2)

если вы считаете, что обходной путь не является хорошим, есть 2 варианта.

1) Используйте тот же обходной путь, но сделайте его более логичным. Измените тип возвращаемого значения isAlreadyActivation () на Boolean вместо Boolean. В методе isAlreadyActivation (), если isValidActivationCode () имеет значение false, возвращает ноль.

http://docs.oracle.com/javaee/6/api/index.html?javax/validation/constraints/package-summary.html

Согласно API выше, null считаются действительными. Таким образом, ваша логика становится более понятной. истина = действительный, ложь = недействительный, ноль = не применимо. Вы можете поместить то же самое в javadoc для этого метода также.

 @AssertTrue(message="{invalidCode}")
    private boolean isValidActivationCode() { ... }


    @AssertTrue(message="{alreadyActivated}")
    private Boolean isAlreadyActivated() {

         if(isValidActivationCode()) {
               <logic for="" isalreadyactivated="">
          } else {
             return null;
           }

    }
</logic>

2) Перейти на пользовательские ограничения. @AssertTrue встроен в ограничение & JSF ребята знают, что их недостаточно. Таким образом, они дали право создавать свои собственные. Так что иди на это. Ниже ссылки для того же.

http://docs.jboss.org/hibernate/validator/4.0.1/reference/en/html/validator-customconstraints.html

Проверка JSR 303, если одно поле равно "что-то"то эти остальные поля не должны быть нулевыми

Я думаю, это все, что у нас есть, выбор за вами :)

 Menno23 окт. 2012 г., 10:57
Похоже, для этого нет готового решения. Я ценю ваши дополнительные исследования, я работал с моим обходным путем, но я буду использовать вашnull-растворение, так как это похоже на лучший результат. Позже я приложу некоторые усилия к созданию пользовательских валидаторов, хотя думаю, что сейчас я могу лучше потратить свое время в этом проекте. Как сказал, спасибо Рави.
Решение Вопроса

я не могЯ не могу углубиться в аннотацию JSF, но мне любопытно, почемуt Вы просто вызываете isValidActivationCode () в isAlreadyActivation () также, например, как показано ниже,

@AssertTrue(message="{invalidCode}")
private boolean isValidActivationCode() { ... }


@AssertTrue(message="{alreadyActivated}")
private boolean isAlreadyActivated() {

     if(isValidActivationCode()) {
           <logic for="" isalreadyactivated="">
      )

}
</logic>
 Menno22 окт. 2012 г., 15:36
Потому что таким образом метод isAlreadyActivation все равно будет выполнен, и мое сообщение все равно будет брошено. Единственный способ, которым я мог манипулировать этим, всегда выдавать true в случае неверного кода, поэтому это никогда не приведет к нарушению. Но это'это как обходной путь вместо хорошего решения, не так ли?не так ли?
 Ravi K23 окт. 2012 г., 07:43
Да, вы правы, это просто обходной путь. Если вы хотите пойти на идеальное решение, то это будет немного сложнее. Позвольте мне дать вам еще 2 варианта в следующем ответе.

Ваш ответ на вопрос