- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
<?php
$form = new Validator;
$form
->newString(Request::get('nickname'));
->addRules(
new FW\Rules\NotEmpty(),
new FW\Rules\Length(4, 16),
new FW\Rules\RegExp('/^[a-z]+$/i')
);
->newString(Request::get('password'))
->addRules(
new FW\Rules\NotEmpty(),
new FW\Rules\MinLength(3),
new App\Rules\PasswordStrength(40)
);
->newString(Request::get('confirm'))
->addRules(
new FW\Rules\NotEmpty(),
new FW\Rules\Equals(Request::get('password'))
)
->newString(Request::get('email'))
->addRules(
new FW\Rules\NotEmpty(),
new FW\Rules\ValidEmail(Request::get('email'))
);
if ($form->isValid()) {
reg_user(Request::get('nickname'), Request::get('password'), Request::get('email'));
} else {
print_r($form->getErrors());
}
Надо было от класса Validator унаследовать userRegisterValidator, который бы всё это в конструкторе создавал... А потом ему в некий метод кидались бы поля, а он возвращал результат проверки и ошибки... А так смысл то? Заменить три строчки проверки if preg_match else на кучу всяких new и -> прочей фигни...
Вот не удивлюсь, если на сайте существуют две одинаковые формы, для каждой из который написан такой вот повторно используемый код =]
(j/k)
и плюс прописывание правил для ключей а не ключей для правил
в результате куча копипаста
Это называется ООВ -- объектно ориентированный выпендрёж.
Мол, я знаю new class public и много других страшных слов.
Уж если не умеют так, делали бы по-другому... Но они будут упорствовать до хрипоты, что они делают ООП, и это круто.
Хочу узнать, какие же преимущества есть у объектного кода перед моим?
Если выигрыша нет, то данный говнокод есть ни что иное, как ООП ради ООП`а, который в случае Java ещё был бы оправдан, но в случае php является просто увеличением энтропии Вселенной и приближает нас к неминуемой тепловой смерти... ( про энтропию j/k)
таке злоебуча хуйня не разу не прокатит, и пых пошлет вас нахуй с вашей подобией головы.
;
->ololo()
Действительно userRegisterValidator, вероятно, ни где больше использоваться не будет (хотя и это совершенно не обязательно). И это был пример того, что стоило бы сделать. Сделать полиморфный валидатор, наследный валидатор. Потому что многие формы похожи. Нужно из таких форм конструктивные куски выделять. А прямое использование приведённого метода, приведёт к страшной копипасте... Две совершенно одинаковые формы будут просто скопированы, вместо того, чтобы использовать уже созданный объект, или хотя бы создать в одну строчку тот же самый, использовать прописанное повторно.
разве не логично, что две одинаковые формы должны обрабатываться одним контроллером?
Может быть и другое. Например, многие формы имеют три одинаковых поля с одинаковой проверкой, хотя формы разные: регистрация пользователя, комментарий, загрузка нового стиха пользователем. Не выгоднее ли создать один общий контроллер для одинаковых полей, а затем конкретизировать его для каждой формы доопределив те поля, которые в них уникальны?
Если таких пересечений мало или их нет вообще, значит сущность "формы" не нужна. Её вообще не должно быть в проекте. Должна быть сущность валидатора поля и именно к ней должны цепляться данные, потому что уж одинаковые поля с одинаковой проверкой точно встречаются.
Либо на не нужна сущность формы -- она уже превысила необходимое, либо она слишком абстрактна и от неё есть полиморфные производные, которые действительно используются.
Лев состоит из лап, головы, хвоста и туловища. Мы будем создавать сущность льва или будем конструировать его из лап и хвостов? Ответ на вопрос должна дать задача. Используем ли мы льва? Есть ли в этом смысл? Если мы сначала создаём льва, а потом отдельно используем от него лапы, то зачем лев? Но если у нас есть львы и львицы, например, то странно не ввести льва и не унаследовать от него самца и самку.
Про "хитрость" проекта с Вами абсолютно согласен! Можно проектировать так, что классы-валидаторы будут использоваться в разных местах.
Плодит сущности это MinLength и Length.
->newString(Request::get('nickname'));->addRules( - что это за синтаксис (; не должно тут быть)?
А вот это new FW\Rules\NotEmpty()
Если уж придумываете коды, так хоть пишите синтаксически правильно
Похоже на то.
Там одну точку с запятой нужно из верхнего выражения опустить за пассворд.
Наверное это и стало причиной того, что автор обнаружил этот код. При парсинге произошла ошибка, Mitusbka полез поглядеть и ... Возможно это просто сохранена оригинальная пунктуация.
Это часо не неймспейсы юзаются?
; это опечатка скорее
а уж о неймспейсах стыдно не знать =)
Ps. Введено то в 5.3 а планировалось давненько уже
люди на них смотрят и свято верят что это эталон и надо его придерживаться =\
То есть вы видеть здесь что-то иное, чем
?
Так расскажите нам, в чём преимущество кода.
Вот мой код тоже читаемый, очень хорошо читаемый, и более эффективный.
Так где подвох-то?
Тут сообщения нельзя править.
/^[a-z]{4,16}$/i
тупой кодинг по шаблону Java'ы
А в примере — ООП ради ООП. Как эксперимент или пример — забавно, как часть проекта — перебор.
DOM не для валидации ни разу