Я пытаюсь записать проверки для play-framework и увидеть две разные возможности. Я описал и то, и другое, и хочу знать, правильно ли мое понимание (так что это больше учебник, чем вопрос, особенно потому, что я не получил никакого ответа, что что-то пропустил). Итак, какие возможности существуют.
- Простой способ: расширение класса
Check
:
Преимущества: проще писать, читать легче Недостатки: вы не можете параметризовать проверку, вы можете определить только сообщение. - Расширенный способ: Написание чек на основе OVal
AbstractAnnotationCheck
.
Преимущества: вы можете параметризовать проверку и упростить использование аннотации
Недостатки: немного сложнее.
Прежде чем мы посмотрим на реализацию, я хочу объяснить сообщения. Вы всегда можете установить сообщение напрямую или использовать ключ для отправки сообщения в свойствах сообщений. Последний - чище и рекомендуется. Каждая проверка имеет минимальный 1 параметр: имя недопустимого свойства. Поэтому проверка или проверка определенных параметров всегда упоминаются с %i$s
, где i > 1. Формат строки сообщения должен соответствовать правилам Formatter, но я не уверен, поддерживаются ли все функции. Насколько мне известно, только% s,% d и% f поддерживается с позиционированием. Итак, %[argument_index$][flags]conversion
, где преобразование может быть только s, d или f.
Давайте посмотрим на два примера: Простой способ, который я использовал в своем модуле для оптимистической блокировки:
/**
* Check with proof if the version of the current edited object is lesser
* than the version in db.
* Messagecode: optimisticLocking.modelHasChanged
* Parameter: 1 the request URL.
* Example-Message: The object was changed. <a href="%2$s">Reload</a> and do your changes again.
*
*/
static class OptimisticLockingCheck extends Check {
/**
* {@inheritDoc}
*/
@Override
public boolean isSatisfied(Object model, Object optimisiticLockingViolatedValue) {
//The comparision of version was made in the setter. Here
//we only have to check the flag.
if (((VersionedModel) model).optimisiticLockingViolated) {
final Request request = Request.current();
//The following doesn't work in 1.0 but in 1.1 see https://bugs.launchpad.net/play/+bug/634719
//http://play.lighthouseapp.com/projects/57987-play-framework/tickets/116
//setMessage(checkWithCheck.getMessage(), request != null ? request.url : "");
setMessage("optimisticLocking.modelHasChanged", request != null ? request.url : "");
}
return !((VersionedModel) model).optimisiticLockingViolated;
}
}
Вы используете эту проверку с аннотацией @CheckWith(value=OptimisticLockingCheck.class, message="optimisticLocking.modelHasChanged")
Итак, давайте поближе посмотрим, как это работает. Единственное, что нам нужно сделать, это расширить класс play.data.validation.Проверьте и перезапишите метод isSatisfied. Там вы получите свою модель и значение свойств. Все, что вам нужно сделать, это вернуть true, если все в порядке или false в противном случае. В нашем случае мы хотим установить текущий URL-адрес в качестве параметра. Эта можно легко сделать, вызвав setMessage(). Мы даем сообщение или ключ сообщения, который определяется в свойствах сообщений и параметрах. Помните, что мы предоставляем только один параметр, но называемый% 2 $s, потому что первым параметром всегда является имя свойства.
Теперь сложный способ, основанный на проверке диапазона: Сначала нам нужно определить аннотацию
/**
* This field must be lower than and greater than.
* Message key: validation.range
* $1: field name
* $2: min reference value
* $3: max reference value
*/
@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.FIELD, ElementType.PARAMETER})
@Constraint(checkWith = RangeCheck.class)
public @interface Range {
String message() default RangeCheck.mes;
double min() default Double.MIN_VALUE;
double max() default Double.MAX_VALUE;
}
а затем Check
@SuppressWarnings("serial")
public class RangeCheck extends AbstractAnnotationCheck<Range> {
final static String mes = "validation.range";
double min;
double max;
@Override
public void configure(Range range) {
this.min = range.min();
this.max = range.max();
setMessage(range.message());
}
public boolean isSatisfied(Object validatedObject, Object value, OValContext context, Validator validator) {
requireMessageVariablesRecreation();
if (value == null) {
return true;
}
if (value instanceof String) {
try {
double v = Double.parseDouble(value.toString());
return v >= min && v <= max;
} catch (Exception e) {
return false;
}
}
if (value instanceof Number) {
try {
return ((Number) value).doubleValue() >= min && ((Number) value).doubleValue() <= max;
} catch (Exception e) {
return false;
}
}
return false;
}
@Override
public Map<String, String> createMessageVariables() {
Map<String, String> messageVariables = new TreeMap<String, String>();
messageVariables.put("2-min", Double.toString(min));
messageVariables.put("3-max", Double.toString(max));
return messageVariables;
}
}
OK Я думаю, что аннотация не должна быть объяснена. Давайте посмотрим на чек. В этом случае оно продолжается net.sf.oval.configuration.annotation.AbstractAnnotationCheck
. Мы должны написать configure-метод, где мы получаем аннотацию и можем скопировать параметры. Затем мы должны определить наш чек. Что является аналогом реализации другой проверки. Поэтому мы пишем только наше условие и возвращаем true или false, кроме одной специальной строки! Если мы использовали параметризованное сообщение, мы должны вызвать requireMessageVariablesRecreation();
в нашем методе.
По крайней мере, мы должны переопределить метод createMessageVariables
. Здесь мы должны получить littlebit play-knowlegde (все остальные вещи описаны здесь). Вы помещаете свои сообщения на карту с ключом и значением, но воспроизведение принимает только значения (см. ValidCheck.java
в коде рамки). Таким образом, на нее будет ссылаться позиция. Именно по этой причине я изменил реализацию RangeCheck
, используя TreeMap
вместо HashMap
. Кроме того, я даю ключам начать с индекса, который они могут отнести.
Поэтому я надеюсь, что это станет более понятным, как писать пользовательские проверки/проверки для игры. Я надеюсь, что описание будет правильным. Поэтому вопрос в том, что я правильно понимаю?