Рубрика «validator»

Доброго времени суток!

Спустя некоторое время решил вновь написать сюда и поделиться своим опытом. На этот раз статья будет о том, как кастомизировать стандартные валидаторы, и вызывать их там, где нам будет нужно, используя Spring — аспекты. Ну а сподвигло меня на написание — практически отсутствие подобной информации, особенно на русском.

Проблема

Итак, суть приложения примерно такова: есть gateway — api, который принимает запрос, а в дальнейшем модифицирует и перенаправляет его соответствующему банку. Вот только запрос для каждого из банков отличался — как и параметры валидации. Поэтому валидировать изначальный запрос не представлялось возможным. Тут было два пути — использовать аннотации из javax.validation, либо писать свой отдельный слой валидации. В первом случае была загвоздка — по умолчанию объекты можно валидировать только в контроллере. Во втором случае так-же были минусы — это лишний слой, большое количество кода, да и в случае изменения моделей, пришлось бы менять и валидаторы.

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

Дергаем валидаторы

Спустя пару часов копания в гугле были найдены пару решений, самое адекватное из которых было заавтовайрить javax.validation.Validator и вызвать у него метод validate, которому в качестве параметра нужно передать валидируемый объект.

Казалось бы, решение найдено, но автовайрить везде валидатор не казалось хорошей идеей, хотелось более элегантного решения.

Добавляем АОП

Недолго думая я решил попробовать адаптировать под это решение мною всеми любимые аспекты.

Логика была примерно следующей: создаём аннотацию, и вешаем её над методом который преобразует один объект в другой. Дальше в аспекте перехватываем все методы помеченные этой аннотацией и вызываем метод validate для возвращаемого ими значения. Профит.
Читать полностью »

Если вспомнить все ТЗ с описаниями валидации полей — они всегда выглядили примерно так:

  • не должно быть короче 6 символов
  • не должно превышать 12 символов
  • должно включать только латинские символы, цифры и знак подчёркивания

Требования часто приходят набором простых однозначных фраз. А мы, программисты, переводим эти требования в код.

Можно превращать их в одно ультимативное регулярное выражение, вроде

const validateLogin = login => /^[a-zA-z_d]{6,12}$/.test(login);

Но лучше писать более простые функций которые легче читать и связывать с непосредственным ТЗ:

const charMatch = new RegExp('^[a-zA-Z_0-9]*$');
const validateLogin = login => {
    if (login.length < 6) return false;
    if (login.length > 12) return false;
    if (!charMatch.test(login)) return false;
    return true;
};

А что если ещё сильнее упростить этот код до чего-то вроде:

const validateLogin = login => 
  validate(login)
    .notLessThan(6)
    .notLongerThan(12)
    .hasOnly(['a-z','A-Z','0-9','_']);

Читать полностью »

image

Laravel 5.1, Laravel 5.2, Lara… Код прогрессирует, оптимизируется и развивается. В новой (5.2) версии появился валидатор массивов, например, но что делать, если необходимо провалидировать входящий timestamp? Правильно, писать костыль своё решение.
Читать полностью »

Инженеры из самых больших провайдеров сервисов электронной почты объединились для улучшения защищенности почтового трафика в интернете.

Придуманный инженерами из Google, Microsoft, yahoo, Comcast, Linkedin, 1&1 Mail & Media Development & Technology протокол «SMTP Strict Transport Security» — это новый механизм, который позволяет Email провайдерам определять политики и правила для установления зашифрованных соединений.

Читать полностью »

Или сказ о том, как разработка JSON валидатора превратилась в очередной JSON binding

Пока нормальные разработчики пишут приложения я изобретаю велосипеды.

Наверное многие разработчики сталкивались с ситуацией, когда мобильное приложение разрабатывается параллельно с бэкэндом. При этом частенько структуры данных, приходящие в ответ на запрос с сервера, могут меняться. Например, на стороне бэкэнда решат поменять именование одного из ключиков JSON-а, забыв предупредить о этом мобильную команду. Я уже не говорю про ситуации, когда CamelCase нотацию «внезапно» решили поменять на underscore или наоборот. Вы можете сказать, что налицо плохая организация процесса и недостаток общения команд, и будете абсолютно правы. Но когда приложение на смартфоне заказчика перестает работать на демо все взгляды устремляются на мобильщиков.

Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js