Подтвердить что ты не робот

Как написать пользовательские проверки/валидации для игровой платформы

Я пытаюсь записать проверки для 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. Кроме того, я даю ключам начать с индекса, который они могут отнести.

Поэтому я надеюсь, что это станет более понятным, как писать пользовательские проверки/проверки для игры. Я надеюсь, что описание будет правильным. Поэтому вопрос в том, что я правильно понимаю?

4b9b3361

Ответ 1

По крайней мере, ваш первый пример окажется на правильном пути. Вы можете сравнить его с документацией, приведенной ниже, но я бы предположил из сложности вашего примера, о которой вы уже говорили.

http://www.playframework.org/documentation/1.1/validation#custom

Я не знаю достаточно о структуре воспроизведения, чтобы прокомментировать второй пример.