Как правильно сделать валидаци формы?

Question

[SHNM]

Здравствуйте! Подскажите пожалуйста, как правильно сделать валидацию? Писать куча if, я считаю бред полный, как лучше сделать?

У меня идея такая, я буду создавать массив и в нём указывать, какое поле проверять и т.д.

Comments

[Дмитрий]

Совет спрашиваете?

[SHNM]

Дмитрий, ну да, как лучше сделать без использование каких-либо библиотек

[Дмитрий]

SHNM, ну как угодно, даже через проверки if

[SHNM]

Дмитрий, Вы возможно не читали, что я написал

Писать куча if, я считаю бред полный

[Олег]

SHNM, покажи, что не считаешь бредом в таком случае?
Тебе не предлагают задавать уcловие для каждого поля в отдельности!
Есть циклы для этого. if(el.required)

[SHNM]

Олег, Чувак, создавать кучу проверок, это зашквар и это скажет не только я, видимо ты мамкин программист, что думаешь, что куча проверок это топ.

[SHNM]

Олег,

function validate(array $request)
{
    $errors = [];

    if (!isset($request['email']) || strlen($request['email']) == 0) {
        $errors[]['email'] = 'Email не указан';
    } elseif (!filter_var($request['email'], FILTER_VALIDATE_EMAIL)) {
        $errors[]['email'] = 'Неправильный формат email';
    } elseif (strlen($request['email']) < 4) {
        $errors[]['email'] = 'Email должен быть больше 4х символов';
    } elseif (isEmailAlreadyExists($request['email'])) {
        $errors[]['email'] = 'Email уже используется';
    }

    if (!isset($request['name']) || empty($request['name'])) {
        $errors[]['name'] = 'Имя не указано';
    }

    if (!isset($request['password']) || empty($request['password'])) {
        $errors[]['password'] = 'Пароль не указан';
    }

    if (!isset($request['repeat-password']) || empty($request['repeat-password'])) {
        $errors[]['repeat-password'] = 'Нужно повторить пароль';
    } elseif ((isset($request['password']) && isset($request['repeat-password'])) && ($request['password'] != $request['repeat-password'])) {
        $errors[]['repeat-password'] = 'Пароли не совпадают';
    }

    return $errors;
}

Для тебя это крутой код?

[Олег]

SHNM,

Для тебя это крутой код?

- это секс.
Зачем передавать данные, которые на фронте изначально отсеять можно?
И опять же не для каждого поля, а в цикле

[SHNM]

Олег, если ты будешь писать вот такой код

function validate(array $request)
{
    $errors = [];

    if (!isset($request['email']) || strlen($request['email']) == 0) {
        $errors[]['email'] = 'Email не указан';
    } elseif (!filter_var($request['email'], FILTER_VALIDATE_EMAIL)) {
        $errors[]['email'] = 'Неправильный формат email';
    } elseif (strlen($request['email']) < 4) {
        $errors[]['email'] = 'Email должен быть больше 4х символов';
    } elseif (isEmailAlreadyExists($request['email'])) {
        $errors[]['email'] = 'Email уже используется';
    }

    if (!isset($request['name']) || empty($request['name'])) {
        $errors[]['name'] = 'Имя не указано';
    }

    if (!isset($request['password']) || empty($request['password'])) {
        $errors[]['password'] = 'Пароль не указан';
    }

    if (!isset($request['repeat-password']) || empty($request['repeat-password'])) {
        $errors[]['repeat-password'] = 'Нужно повторить пароль';
    } elseif ((isset($request['password']) && isset($request['repeat-password'])) && ($request['password'] != $request['repeat-password'])) {
        $errors[]['repeat-password'] = 'Пароли не совпадают';
    }

    return $errors;
}

То и зарплата у тебя будет как и твой код

[Олег]

SHNM, Гуглом для своих возможностей научись пользоваться для начала. https://www.w3schools.com/php/php_form_validation.asp

[SHNM]

Олег, Ты внатуре приколы тут лепишь? Вопрос заного почитай. Та и вообще, я не жду помощи от тебя, я у же понял какой ты программист и как ты помогаешь. Сидит за экраном и только умничает

[index0h]

SHNM,

if (!isset($request['email']) || strlen($request['email']) == 0) {
        $errors[]['email'] = 'Email не указан';
    }

Рекомендую добавить еще одну проверку: is_string после isset. Следующий пример для 7ки бросит ворнинг, для 8ки - фатал.

?email[]=not&email[]=email

[SHNM]

index0h, Вы хотите сказать, что это отличный вариант?

if (!isset($request['email']) || strlen($request['email']) == 0) {
        $errors[]['email'] = 'Email не указан';
    }
if (!isset($request['email']) || strlen($request['email']) == 0) {
        $errors[]['email'] = 'Email не указан';
    }
if (!isset($request['email']) || strlen($request['email']) == 0) {
        $errors[]['email'] = 'Email не указан';
    }
if (!isset($request['email']) || strlen($request['email']) == 0) {
        $errors[]['email'] = 'Email не указан';
    }
if (!isset($request['email']) || strlen($request['email']) == 0) {
        $errors[]['email'] = 'Email не указан';
    }
if (!isset($request['email']) || strlen($request['email']) == 0) {
        $errors[]['email'] = 'Email не указан';
    }

Ведь можно так

$arr = [
   "email" => [
       "required" => true,
       "filter" => "email",
       "min" => 2,
       "max" => 16
    ]
];

И т.д

[index0h]

SHNM,

Вы хотите сказать, что это отличный вариант?

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

Ведь можно так

Можно все что угодно. Правильно ли это - другой вопрос. Меньше писать - далеко не всегда лучше. DRY по которому бездумно текут многие инженеры тоже далеко не всегда стоит придерживаться.
min/max у вас не соотатствуют почте.

[FanatPHP]

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

[index0h]

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

[index0h]

FanatPHP, часто фронт вполне резонно обязать выполнять базовые проверки введенных данных.
Полная проверка на бэке все равно будет присутствовать, но необходимость выводить список ошибок довольно часто пропадает. Пример: форма авторизации с логином и паролем часто требует не выводить ошибки типа "пользователь с таким логином не найден", или "не правильный пароль для пользователя", вместо этого с точки зрения безопасности правильней выводить "не правильный логин, или пароль". Для таких ситуаций вполне норм бросать исключение.
Если взять за основу пример автора, что у нас могут быть за ошибки? Не ожидаемые рассматривать не будем.
1. Не введена почта - фронт
2. Введенная почта не соответствует формату - фронт
3. Почта уже зарегистрирована - бэк
4. Почта в disposable списке - бэк
5. Не указано имя - фронт
6. Пароль не соответствует требованиям - фронт
7. Пароль не соответствует подтвержденному - фронт
Если на фронте обнаружена ошибка ввода - слать на бэк запрос не имеет смысла. Что имеем в итоге?
Ожидаемые ошибки на бэке (которых не на фронте) - это только проверка почты, одно поле. Для него добавить исключение вполне резенно. Если на бэке получили например не корректный пароль и почту - либо фронт не справился, либо кто-то с курлом играется, вполне нормально ответить первой обнаруженной ошибкой.

[FanatPHP]

index0h, ну вообще согласен, если за проверки отвечает фронт, то на бэке можно не цацкаться

[SHNM]

FanatPHP, ну вроде как, проверки на фронте тоже херня еще та, спокойно можно её обойти, уже обходил, чисто для проверки пробывал

[index0h]

FanatPHP, Для сложных форм, например с выбором либо поля А1 и А2, либо Б1, Б2 и Б3 вам так или иначе прийдется дополнять валидацию кастомщиной. В лучшем случае это будет в конкретном обработчике формы, в худшем - будем пытаться расширять валидатор.
В самом хреновом сценарии валидатор превратится в вундервафлю, содержащую и локализатор, и роутер, будет уметь в кэш сревера, сессии, какую-нить рекаптчу через гугловую либу, делать запросы для валидаци disposable почт, и т.д.

[FanatPHP]

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

[FanatPHP]

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

[SHNM]

FanatPHP, ору, чел, я чисто написал, моё личное мнение.

[SHNM]

FanatPHP, ещё раз повторю, проверки на js, спокойно можно обойти

[FanatPHP]

SHNM, ради бога, пиши никто тебе не запрещает. Ты все правильно написал.
Просто ты не совсем понял, что сказал index0h. Если проверки только на клиенте - то да, это ерунда, тут ты прав.
Но если проверка есть и на клиенте и на сервере, то сервер тогда может не напрягаться с красивым оформлением ошибок. Вот о чем говорил index0h

[FanatPHP]

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

[index0h]

SHNM,

ну вроде как, проверки на фронте тоже херня еще та, спокойно можно её обойти, уже обходил, чисто для проверки пробывал

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

FanatPHP,

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

Валидатор - такая штука, которую лучше по возможности не расширять и не усложнять.

Если честно, то мне дико нравится ларавелевский - краткий, мощный, ёмкий, гибкий.

Все очень зависит от того, с чем вы сравниваете и по каким параметрам. В рамках ko-ko-ko/php-assert я очень сильно угорел по производительнсоти, если по сравнению с нейтивными проверками ларавелевский вариант медленее хотя бы в 40 раз - это отличный результат. Например статику я использовал не из соображений удобства, а что бы не тратить время на вызов конструктора.
Лично я пропагандирую обязательную валидацию аргументов в каждом методе, это люто упрощает поддержку, но сложные валидаторы (особенно с декларативными настройками) тут не применимы, это слишком медленно.

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

[SHNM]

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

[SHNM]

FanatPHP, Не злись, все будет чики пуки, родной

[SHNM]

index0h, а смысл их два раза проверять? Смысла та нет все равно, лучше 1 раз проверит на back-end'e и все.

[FanatPHP]

Ну я вижу тебя надо учить, словами ты не понимаешь.

[SHNM]

FanatPHP, так научи и не умничай, цём

[index0h]

SHNM, Автор, вам нужно узнать ответ на вопрос, или быть забаненным?
Если первое - пожалуйста умерьте свой пыл и возвращайтесь к культурному разговору.
Если второе - продолжайте в том же духе, но это будет не долго.

[index0h]

SHNM,

а смысл их два раза проверять? Смысла та нет все равно, лучше 1 раз проверит на back-end'e и все.

Прочитайте внимательно

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

Как доп ачивка - можно упростит вывод ошибок.

[SHNM]

index0h, а смысл? Это можно сделать и на бэкенде, зачем тратить личное время, чтобы написать это чушь и на фронте? Смысла тут 0

[SHNM]

index0h, та и вообще, не спорите Вы, ребята :) мурр

[index0h]

SHNM,

а смысл? Это можно сделать и на бэкенде, зачем тратить личное время, чтобы написать это чушь и на фронте? Смысла тут 0

Смысл в том, что бы не заставлять пользователя вводить все, потом получать ошибки и требовать от него все исправить. Если фронт делает проверки сразу - пользователь сразу же исправляет косяки. А сервер не обрабатывает зарнее не валидные данные.
Если фронт проверку обойти - в чем проблема, бэк все равно вернет 400 ошибку. Много вы знаете леюдей, которые регулярно пользуются dev tools браузера, или курлом?
Я занимаюсь веб разработкой с 2007го, а вы?

[SHNM]

index0h, ну я явно не с 2007 года :) у меня стаж 5-6 лет

[SHNM]

index0h, та и стаж тут не как не влияет, есть люди, которые занимаются разработкой 3 года и знают больше, чем другие выучили за 13 лет

[index0h]

SHNM,

ну я явно не с 2007 года :) у меня стаж 5-6 лет

Странно, через 5-6 лет опыта вопросов об необходимости валидации на фронте возникать не должно... Особенно в связи с тендециями развития фронта и повсеместной разработке SPA.

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

Согласен, важно качество опыта, с 2011 года я занимался только долгоживущими веб-системами в продуктовых компаниях. Собственно по этой причине я не обращаю внимание на то меньше, или больше писать.
Действительно важные метрики для кода:
- читаемость
- изменяемость
- переносимость
- связность/зацепление
- производительность
- тестируемость
и только в последнюю очередь лаконичность.
Хотите писать код, за который вас потом не будут проклинать другие инженеры используйте - свод правил: https://github.com/index0h/php-conventions Этот список мягко говоря жесткий, он не для сайтиков, но он очень экономит время, нервы и кровь из глаз на длительных проектах.

[SHNM]

index0h, ну типо ты не понял, у меня стаж 5-6 лет в пхп, html, css, js :)

[index0h]

SHNM,

ну типо ты не понял, у меня стаж 5-6 лет в пхп, html, css, js :)

почему же?)) Мне все ясно и очевидно.

Вам по моим аргументам есть что противопоставить?))

Answer 1

[index0h]

Писать куча if, я считаю бред полный, как лучше сделать?

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

У меня идея такая, я буду создавать массив и в нём указывать, какое поле проверять и т.д.

Разнося правила валидации и непосредственно валидацию вы усложняете код: вместо одного места проверки вы получаете как минимум два (одно - конфигурация, другое проверка).
Если собираетесь конфигурировать ваш валидатор строками/массивами вы тоже увеличите сложность.

Можете сюда еще взглянуть: https://github.com/ko-ko-ko/php-assert

Answer 2

[FanatPHP]

В принципе рациональное зерно в твоих рассуждениях есть.

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

Comments

[SHNM]

Ну как я понял, второй вариант мой лучше, да?

[FanatPHP]

Ну ты его сначала реализуй, "без использование каких-либо библиотек", а потом посмотрим, какой лучше :)

[SHNM]

FanatPHP, ну я тип уже знаю как его реализовать, типо по ролям :)
Он будет типо вот такой

$arr = [
   "email" => [
       "required" => true,
       "filter" => "email"
    ],
    "password" => [
        "required" => true,
        "min" => 8,
        "max" => 16
     ]
];
form($arr);

А саму функцию, тоже знаю как :)

[FanatPHP]

а зачем паролю максимальная длина?
и где здесь проверка емейла на уникальность?

[SHNM]

FanatPHP, ну типо все это будет происходить в функции, я в массив я буду добавлять, что мне нужно

[FanatPHP]

ну попробуй