Что такое валидация простыми словами

Поддержка проверки браузерами

Разработчики браузеров добавляли поддержку проверки в свои продукты по частям, вследствие чего некоторые версии браузеров поддерживают одни возможности валидации, но не обращают внимания на другие. В таблице ниже указаны минимальные версии браузеров, полностью поддерживающих валидацию HTML5:

Поддержка проверки браузерами
Браузер IE Firefox Chrome Safari Opera Safari iOS Android
Минимальная версия 10 4 10 5 10

Так как проверка HTML5 не заменяет валидацию на стороне сервера, ее можно рассматривать как второстепенную возможность, когда даже такая несовершенная поддержка лучше, чем отсутствие вообще какой-либо поддержки. В браузерах, не поддерживающих проверку, таких как IE 9, можно отправлять формы с некорректными данными, но эти ошибки можно выявить на стороне сервера и возвратить эту страницу назад браузеру, но с указанными ошибками.

С другой стороны, ваш веб-сайт может содержать сложные формы, в которых можно сделать массу ошибок при вводе данных, и вы не хотите потерять тех IE-пользователей, которые после первой неудачной попытки заполнить вашу форму не предпримут другую. В таком случае у вас есть два пути: разработать и использовать свою систему проверки или же использовать библиотеку JavaScript, чтобы компенсировать умственную отсталость IE. Какой из этих двух подходов выбрать, зависит от объема и сложности проверки.

На странице HTML5 Cross Browser Polyfills можно найти длинный список библиотек JavaScript, которые все, по большому счету, делают то же самое. Одна из лучших среди этих библиотек — это webforms2.

Библиотека webforms2 реализует все рассмотренные на данный момент атрибуты. Для использования библиотеки загрузите все ее файлы в папку своего веб-сайта (а лучше в подкаталог папки веб-сайта) и добавьте в веб-странице ссылку на эту библиотеку.

Библиотека webforms2 хорошо интегрируется с другой заплаткой JavaScript, называющейся html5Widgets. Она реализует поддержку возможностей форм, которые мы рассмотрим далее, таких как ползунок и средства выбора даты и цвета. Обе эти библиотеки предоставляют хорошую общую поддержку для веб-форм, но содержат в своем коде неизбежные пробелы и незначительные ошибки. Качество сопровождения и усовершенствования этих библиотек покажет только время.

Что означает W3C?

Аббревиатура W3C (World Wide Web) обозначает сообщество единых стандартов.

Еще со времен зарождения Всемирной паутины этот консорциум определил единые стандарты для всех веб-страниц с целью правильного отображения их различными браузерами.

С развитием Сети между создателями различных браузеров постоянно ведется ожесточенная борьба за первенство.

И были времена, когда разработчики даже пытались внедрить свои собственные стандарты.

Однако первоисточнику удалось сохранить стандарты таких веб-страниц, какими мы видим их сейчас.

И сегодня веб-мастерам остается лишь придерживаться этих правил при создании ресурсов.

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

В этой статье мы будем много говорить о стандартах HTML, и в связи с этим возникает резонный вопрос: а для чего вообще они были введены?

Первоочередной задачей таких стандартов является обеспечение совместимости.

До их введения разработчики особо не заботились о том, как сайты будут отображаться на других устройствах.

Как правило, веб-ресурс создавался под конкретный браузер, устройство.

Но с развитием технологий пришло понимание необходимости создать единый стандарт языка разметки веб-страниц.

Это делает работу в Сети удобной для большинства пользователей, независимо от того, в какой части света они находятся и какой браузер используют.

Итак, целью утверждения стандартов html является:

  • доставить максимальную пользу наибольшему количеству веб-пользователей;
  • обеспечить долгосрочную жизнеспособность любого веб-документа;
  • упростить код и снизить стоимость производства;
  • предоставлять сайты, которые доступны большему количеству людей и большему числу типов электронных устройств;
  • продолжать работать корректно по мере развития браузеров и появления новых устройств на рынке.

Как проверить сайт на валидность

Для проверки безукоризненности кода чаще всего используют очень полезный сайт валидатор «Markup Validation Service», расположенный по адресу: http://validator.w3.org, созданный компанией W3C.

HTML

Здесь перед Вами три варианта валидации:

  • ввести URL-адрес страницы;
  • загрузить файл с кодом со своего компьютера;
  • вставить готовый код в форму.

Сервис указывает не только на ошибки html кода и их расположение, но и даёт советы по исправлению. Если код уже имеется в Сети, то можно произвести валидацию путём введения её URL-адреса в форму «Validate by URL» и нажатия кнопки Check. Валидатор HTML включит считывание кода и сообщит об итогах.

Необходимо вводить именно адрес проверяемой URL-страницы. Весь сайт проверяться не будет. Введёте адрес сайта — программой считается только его главная страница. В случае нахождения замечаний выходит уведомление о невалидности программного кода и далее указываются строки с допущенными погрешностями.

В этом видео наглядно объяснён процесс проверки с помощью валидатора:

Проверка локальных файлов

По этому же адресу http://validator.w3.org можно проверить код, выбрав вкладку «Validate by File Upload» и загрузив документ с прописанным код.

Выбираем путь к необходимому файлу и жмём Check. Далее всё происходит аналогично.

Использование формы для ввода кода

Иногда удобней вставить сразу код страницы и проверить его онлайн: выбираем вкладку «Validate by Direct Input» и отправляем весь код на сервер.

CSS

Проверка валидности кода CSS может быть пройдена также онлайн валидатором: https://jigsaw.w3.org/css-validator/

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

Снова можно выбрать — указать URL, загрузить свой файл или вставить код.

Осуществляется проверка сайта на ошибки, как и в случае с HTML, и — получаем ответ от сервера. Настроек проверки не имеется, однако можно изучить предлагаемый сгенерированный валидный код, расположенный после списка недостатков кода.

Пример:

Изучаем полученный код и приводим исходный к нужному виду.

Расширения для браузеров

Для браузеров существуют всевозможные расширения для проверки валидации. Для Google Chrome есть проверяющий валидность кода плагин HTML Tidy Browser Extension, для Opera — расширение Validator, для Safari — Zappatic, для Firefor — HTML Validator.

Остановимся на последнем более детально. Он осуществляет ту же проверку, что и validator, только оффлайн. Взять его можно здесь http://users.skynet.be/mgueury/mozilla/

Устанавливаем расширение, перезагружаем браузер — и можно сразу работать. В случае возникновения заморочек с установкой, можно написать в саппорт Mozilla Firefox или полистать форум http://forum.mozilla-russia.org/doku.php?id=general:extensions_installing

Подробное видео об установке HTML Validator и его использовании:

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

Выглядит результат как небольшая картинка с итогом валидации:

Щёлкнув по результату, можно открыть:
— исходный код;
— ошибки — в левом нижнем блоке (или сообщение о валидности);
— подсказки по исправлению ошибок — в правом нижнем.

Проверка с помощью регулярных выражений

Самым мощным (и самым сложным) поддерживаемым HTML5 типом проверки является проверка на основе регулярных выражений. Поскольку JavaScript уже поддерживает регулярные выражения, добавление этой возможности к формам HTML будет вполне логичным шагом.

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

{3}-{3}

Квадратные скобки в начале строки определяют диапазон допустимых символов. Иными словами, группа разрешает любые прописные буквы от А до Z. Следующая за ней часть в фигурных скобках указывает множитель, т.е. {3} означает, что нужны три прописные буквы. Следующее тире не имеет никакого специального значения и означает самое себя, т.е. указывает, что после трех прописных букв должно быть тире. Наконец, обозначает цифры в диапазоне от 0 до 9, а {3} требует три таких цифры.

Регулярные выражения полезны для поиска в тексте строк, отвечающих условиям, заданных в выражении, и проверки, что определенная строка отвечает заданному регулярным выражением шаблону. В формах HTML5 регулярные выражения применяются для валидации.

Для обозначения начала и конца значения в поле символы ^ и $, соответственно, не требуются. HTML5 автоматически предполагает наличие этих двух символов. Это означает, что значение в поле должно полностью совпасть с регулярным выражением, чтобы его можно было считать корректным.

Таким образом следующие значения будут допустимыми для этого регулярного выражения:

QDR-001
WES-205
LOG-104

А вот эти нет:

qdr-001
TTT-0259
5SD-000

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

Чтобы применить полученное тем или иным путем регулярное выражение для проверки значения поля <input> или <textarea>, его следует добавить в этот элемент в качестве значения атрибута pattern:

Регулярные выражения кажутся идеальным средством для проверки правильности адресов электронной почты. Впрочем, не кажутся, а так оно и есть. Но подождите немного с использованием их таким образом, т.к. в HTML5 уже имеется выделенный тип для адресов электронной почты со встроенным в него регулярным выражением (будет рассмотрен в следующей статье).

Validation messages

You can specify validation message in the decorator options and that message will be returned in the
returned by the method (in the case that validation for this field fails).

import { MinLength, MaxLength } from 'class-validator';

export class Post {
  @MinLength(10, {
    message: 'Title is too short',
  })
  @MaxLength(50, {
    message: 'Title is too long',
  })
  title: string;
}

There are few special tokens you can use in your messages:

  • — the value that is being validated
  • — name of the object’s property being validated
  • — name of the object’s class being validated
  • , , … — constraints defined by specific validation type

Example of usage:

import { MinLength, MaxLength } from 'class-validator';

export class Post {
  @MinLength(10, {
    // here, $constraint1 will be replaced with "10", and $value with actual supplied value
    message: 'Title is too short. Minimal length is $constraint1 characters, but actual is $value',
  })
  @MaxLength(50, {
    // here, $constraint1 will be replaced with "50", and $value with actual supplied value
    message: 'Title is too long. Maximal length is $constraint1 characters, but actual is $value',
  })
  title: string;
}

Also you can provide a function, that returns a message. This allows you to create more granular messages:

import { MinLength, MaxLength, ValidationArguments } from 'class-validator';

export class Post {
  @MinLength(10, {
    message: (args: ValidationArguments) => {
      if (args.value.length === 1) {
        return 'Too short, minimum length is 1 character';
      } else {
        return 'Too short, minimum length is ' + args.constraints + ' characters';
      }
    },
  })
  title: string;
}

Message function accepts which contains the following information:

  • — the value that is being validated
  • — array of constraints defined by specific validation type
  • — name of the object’s class being validated
  • — object that is being validated
  • — name of the object’s property being validated

Принципы верификации

Проверка функциональности необходима для получения доказательств способности продукта или процесса достигать поставленных целей. В неё входят такие критерии:

  • Пригодность. Имеется в виду способность продукта выполнять задачи, которые предписываются ему стандартами и требованиями технического задания;
  • Точность. Необходимо проверить, может ли продукт выдавать результаты с заданной точностью в оговорённом диапазоне входных данных;
  • Безопасность. Здесь нужна верификация не только безопасности пользователя, но и информации, материалов и самой системы;
  • Соответствие. Продукт или процесс должны выдавать предсказуемый результат при использовании оговорённых стандартом условий;
  • Совместимость. Нужно проверить, допускается ли сочетание объекта с товаром или процессами других производителей, также соответствующих стандартам.

Проверка надёжности заключается в тестировании способности товара или процесса поддерживать заданный уровень работы в оговорённых условиях. В неё входят:

  1. Завершённость. Нужно понять, является ли результат применения продукта или процесса достаточным с учетом начальных требований;
  2. Стойкость к ошибкам. Тестирование предполагает проверку функционирования объекта при отклонении входных данных от идеальных;
  3. Устойчивость. Здесь проводится исследование поведения продукта или работы процесса в условиях нестабильной среды;
  4. Способность восстанавливаться. Имеется в виду продолжение выполнения функций после сбоев разной степени критичности.

Проверка удобства пользования выявляет трудности, которые могут возникнуть у пользователей, включая их субъективную оценку. Сюда включаются:

  • Понятность. Включает способность пользователя разобраться в принципах функционирования продукта или процесса;
  • Возможность обучения. Речь идет о диапазоне регулировок, позволяющих адаптировать объект к потребностям разных клиентов;
  • Управляемость. Это верификация возможности управлять продуктом. При хорошей управляемости клиент без труда сменит настройки на желаемые.

Проверка производительности заключается в анализе соответствия результата и объёма израсходованных для его достижения ресурсов. В неё входят:

  • Временное поведение. Нужно убедиться, что график потребления объектом энергии или сырья непосредственно связан с его производительностью;
  • Потребление ресурсов. Здесь проводится количественная оценка расходуемого объема ресурсов и определение пиковых значений;
  • Алгоритмизация. Подразумевается использование оптимальных алгоритмов переработки входящих ресурсов или данных для минимизации потребления.

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

  • Лёгкость анализа. Верификация позволяет понять, нужно ли прикладывать усилия для обнаружения требующих корректировки частей объекта;
  • Изменяемость. Демонстрирует сложность и трудоёмкость непосредственного внесения упомянутых изменений для пользователя;
  • Возможность настройки. Сюда входит изучение способности получения нового результата только за счёт настроек, без переделки всего продукта или процесса;
  • Тестируемость. Позволяет определить, насколько легко проверяется правильная работа изменённой части объекта.

Проверка перемещаемости подразумевает анализ возможности переноса процесса или продукта из одной среды в другую. В неё входят:

  • Приспособляемость. Здесь проверяется способность объекта поддерживать нормальную работу при изменении окружающих условий;
  • Уровень адаптации. Речь идёт о возможности использовать продукт как составную часть более сложных объектов разных видов;
  • Согласованность. Это непосредственная проверка продукта или процесса на предмет соответствия отраслевым стандартам;
  • Возможность замены. Подразумевает вероятность применения объекта вместо аналогичного продукта другого производителя.

5 последних уроков рубрики «HTML5»

  • В этом уроке я покажу процесс создания собственных HTML тегов. Пользовательские теги решают множество задач: HTML документы становятся проще, а строк кода становится меньше.

  • Сегодня мы посмотрим, как можно организовать проверку доступности атрибута HTML5 с помощью JavaScript. Проверять будем работу элементов details и summary.

  • HTML5 — глоток свежего воздуха в современном вебе. Она повлиял не только на классический веб, каким мы знаем его сейчас. HTML5 предоставляет разработчикам ряд API для создания и улучшения сайтов с ориентацией на мобильные устройства. В этой статье мы рассмотрим API для работы с вибрацией.

  • Веб дизайнеры частенько сталкиваются с необходимостью создания форм. Данная задача не простая, и может вызвать головную боль (особенно если вы делаете что-то не стандартное, к примеру, много-страничную форму). Для упрощения жизни можно воспользоваться фрэймворком. В этой статье я покажу вам несколько практических приёмов для создания форм с помощью фрэймворка Webix.

  • Знакомство с фрэймворком Webix

    В этой статье мы бы хотели познакомить вас с фрэймворком Webix. Для демонстрации возможностей данного инструмента мы создадим интерфейс online аудио плеера. Не обольщайтесь — это всего лишь модель интерфейса. Исходный код доступен в демо и на странице GitHub.

Расширения Chrome для проверки HTML

Расширения Chrome предлагают отличный способ расширить ваш браузер с помощью инструментов, которые помогут вам в вашей повседневной работе веб-разработчика. Здесь представлены самые популярные расширения, которые помогут вам с проверкой HTML в Chrome.

Web Developer

Это расширение является обязательным для всех веб-разработчиков, поскольку оно предлагает хороший набор инструментов, которые помогут вам в вашей работе: отключение JavaScript, управление файлами cookie, настройка CSS, формы … а также ссылки для проверки текущей страницы в W3C Validator.

Расширение веб-разработчика предоставляет вам ссылки для проверки HTML (как с помощью URL-адреса, так и путем отправки локального HTML-кода в качестве текстового ввода), CSS, каналов, доступности на волне и проверки наличия неработающих ссылок.

Плюсы: приятно интегрированы с другими инструментами веб-разработки, простой интерфейс.

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

Validity

Расширение Validity позволяет проверять HTML в устаревшем W3C Validator и отображает проблемы, обнаруженные в консоли JavaScript, вместо открытия новой вкладки. Показывает только строку, в которой находится проблема, и общее описание – без начальных и конечных строк и столбцов, без выдержек и ссылок для дополнительной помощи.

Он также может быть немного запутанным, поскольку выходные данные смешиваются с другими предупреждениями JS и журналами, которые выводятся в вашей консоли JS. Вероятно, было бы более читабельным, если бы вывод находился на отдельной вкладке, а не в консоли JS.

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

Минусы: Зависит от действующего валидатора, не может напрямую использовать Nu Validator. Вывод ограничен и грязен, поскольку использует консоль JavaScript.

HTML Validation Bookmarklet

Acid.JS Validator – это бесплатный букмарклет, который использует API синтаксического анализатора W3C SGML для проверки разметки страницы, на которой он вызывается.

Другие расширения которые не работали на момент написания статьи

  • W3C Validator . Не является официальным расширением W3C, оно должно использовать устаревший API валидатора и отображать проблемы на консоли JS, но оно не работает.
  • HTML валидатор . Это не работает, вероятно, потому что у него была опция автозапуска, которая могла привести к его запрету .
  • Kingsquare HTML Validator . Предполагается, что он предлагает альтернативный способ проверки HTML с использованием библиотеки Tidy HTML вместо W3C Validator, он просто не работает.

Что это и зачем

Валидный HTML-код, валидная разметка — это HTML-код, который написан в соответствии с определёнными стандартами. Их разработал Консорциум Всемирной Паутины — World Wide Web Consortium (W3C). Что именно это значит?

Писать код — это примерно как писать какой угодно текст, например, на русском языке. Можно написать понятно, вдобавок грамотно, а также разбить текст на абзацы, добавить подзаголовки и списки. Так и с валидностью кода. Если вы создаёте разметку, которая решает ваши задачи корректно, то для того, чтобы ваша работа была валидной, в ней стоит навести порядок.

Понятный код — меньше хлопот

Для чего это нужно? Иногда нам кажется, что другие думают как мы. Что не надо стараться объяснять. Но вот нет. Чтобы другие поняли вас быстрее, надо учитывать правила передачи информации. Под другими можно иметь в виду коллегу по команде, а также браузер или компилятор — любое ПО, которое будет работать с вашей разметкой.

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

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

Стейкинг валидатора

Стейк — ставка/депозит валидатора необходимый для участия в выборах валидаторов и последующей валидации в Proof-of-Stake блокчейне.

Доход валидатора — валидатор получает вознаграждение по окончании каждого цикла валидации. Доход состоит из двух частей:

  • эмиссия новых токенов (фиксированная в сети на уровне ~0,5% в год);
  • плата за подписанные блоки (1,7 TON за каждый блок в мастерчейне и по 1 TON за каждый блок в шардчейне).

На текущий момент все валидаторы получают вознаграждение пропорционально своему стейку. То есть если валидатор поставил стейк в размере 1% от суммы всех стейков, то и его вознаграждение составит 1% от общего вознаграждения.

Так как размер стейка слишком большой для обычного участника, а количество валидаторов ограничено, то был разработан смарт-контракт DePool. Он позволяет делать стейки «в складчину» любому участнику с небольшой суммой для участия в стейкинге и получения своей части вознаграждения. Смарт-контракт гарантирует то, что валидатор не может использовать средства участников каким-либо другим образом, тем самым участникам гарантируется безопасность их средств от недобросовестности валидатора.

Выборы валидаторов происходят (по текущей конфигурации сети) каждые 18 часов. Каждый период состоит из 3 фаз:

  • выборы открыты, смарт-контракт выборщика принимает новые стейки, а предыдущие валидаторы могут вернуть свои стейки от смарт-контракта выборщика;
  • выборы закончены и смарт-контракт определяет группу валидаторов на следующую фазу;
  • новая группа валидаторов начинает работу. У предыдущей группы валидаторов стейки временно находятся в фазе «заморозки».

Визуально это выглядит так:

Определение группы валидаторов — смарт-контракт выборщика действует по таким правилам:

Атрибут pattern

Атрибут , скорее всего, заставит многих фронтенд-разработчиков прыгать от радости. Этот атрибут принимает регулярное выражение (аналогичное формату регулярных выражений JavaScript), по которому будет проверяться корректность введенных в поле данных.

Регулярные выражения это язык, использующийся для разбора и манипуляции текстом. Они часто используются для сложных операций поиска и замены, а также для проверки корректности введенных данных.

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

Регулярные выражения (RegEX) являются мощным, кратким и гибким инструментом для сопоставления строки текста, вроде отдельных символов, слов или шаблонов символов.

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

Давайте посмотрим на пару примеров использования регулярных выражений для валидации значения полей ввода.

Телефонные номера

Как упоминалось ранее, тип поля  не полностью поддерживается браузерами из-за несоответствия форматов номеров телефонов в разных странах.

Например, в некоторых странах формат телефонных номеров представляется в виде , и сам телефонный номер будет что-то вроде этого: 0803-555-8205.

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

<label for="phonenum">Phone Number:</label>
<input type="tel" pattern="^\d{4}-\d{3}-\d{4}$" >

Буквенно-цифровые значения

Следующий шаблон соответствует набору буквенно-цифровых значений (комбинации букв английского алфавита и цифр):

<input type="text" pattern="+" >

Имя пользователя в Twitter

Данное регулярное выражение соответствует имени пользователя в твиттере, с предваряющим символом @, например:

<input type="text" pattern="^@{1,15}$" >

Цвет в шестнадцатеричном виде

Эта регулярка соответствует цвету в шестнадцатеричном виде, например #3b5998 или #000:

<input type="text" pattern="^#+({6}|{3})$" >

Custom validation decorators

You can also create a custom decorators. Its the most elegant way of using a custom validations.
Lets create a decorator called :

  1. Create a decorator itself:

    import { registerDecorator, ValidationOptions, ValidationArguments } from 'class-validator';
    
    export function IsLongerThan(property: string, validationOptions?: ValidationOptions) {
      return function (object: Object, propertyName: string) {
        registerDecorator({
          name: 'isLongerThan',
          target: object.constructor,
          propertyName: propertyName,
          constraints: property,
          options: validationOptions,
          validator: {
            validate(value: any, args: ValidationArguments) {
              const relatedPropertyName = args.constraints;
              const relatedValue = (args.object as any)relatedPropertyName;
              return typeof value === 'string' && typeof relatedValue === 'string' && value.length > relatedValue.length; // you can return a Promise<boolean> here as well, if you want to make async validation
            },
          },
        });
      };
    }
  2. Put it to use:

    import { IsLongerThan } from './IsLongerThan';
    
    export class Post {
      title: string;
    
      @IsLongerThan('title', {
        /* you can also use additional validation options, like "groups" in your custom validation decorators. "each" is not supported */
        message: 'Text must be longer than the title',
      })
      text: string;
    }

In your custom decorators you can also use .
Lets create another custom validation decorator called :

  1. Create a ValidationConstraint and decorator:

    import {
      registerDecorator,
      ValidationOptions,
      ValidatorConstraint,
      ValidatorConstraintInterface,
      ValidationArguments,
    } from 'class-validator';
    
    @ValidatorConstraint({ async: true })
    export class IsUserAlreadyExistConstraint implements ValidatorConstraintInterface {
      validate(userName: any, args: ValidationArguments) {
        return UserRepository.findOneByName(userName).then(user => {
          if (user) return false;
          return true;
        });
      }
    }
    
    export function IsUserAlreadyExist(validationOptions?: ValidationOptions) {
      return function (object: Object, propertyName: string) {
        registerDecorator({
          target: object.constructor,
          propertyName: propertyName,
          options: validationOptions,
          constraints: ,
          validator: IsUserAlreadyExistConstraint,
        });
      };
    }

    note that we marked our constraint that it will by async by adding in validation options.

  2. And put it to use:

    import { IsUserAlreadyExist } from './IsUserAlreadyExist';
    
    export class User {
      @IsUserAlreadyExist({
        message: 'User $value already exists. Choose another name.',
      })
      name: string;
    }

Валидность и другие показатели качества сайта

Еще многое предстоит сделать по расширению возможностей сервиса, в планах по реализации три дополнительных направления:

  1. Доступность. Соответствие стандарту WCAG (Web Content Accessibility Guidelines), обеспечивающему доступность содержимого сайта для людей с ограниченными возможностями.
  2. Совместимость. Мультиплатформенная совместимость снижает затраты на разработку и позволяет пользователям просматривать сайт в любом браузере.
  3. Оптимизация. Упрощение и минимизация кода, оптимизация графики и контента делает сайт более открытым для поисковых систем и удобным для пользователей.

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

Рекомендую ознакомиться с другими моими обзорами средств анализирования сайта из рубрики Аудит и тестирование. И конечно же жду Ваших отзывов! Как думаете, сервис найдет свое место в нише и будет пользоваться спросом?

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Adblock
detector