Фильтры в rules() модели

[Леонид]

Зачем определяться, если оно не устраивает в комплексе? Были бы валидаторы отдельно - было бы пофиг на порядок.
ПС: отличная шутка

Нет, не пофиг. Порядок важен в любом случае, до вас это не доходит никак.
Пример. Вам нужно проверить email на корректность и на уникальность:
a) email -> unique - ок
б) unique -> email - не ок, если это не email, то запрос излишен.

ПС: Вы прочитали тему с обсуждением другой проблемы, ничего не поняли и начали гнуть свою линию...

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

[Faenir]

Нет, не пофиг. Порядок важен в любом случае, до вас это не доходит никак.
Пример. Вам нужно проверить email на корректность и на уникальность:
a) email -> unique - ок
б) unique -> email - не ок, если это не email, то запрос излишен.

ПС: Вы прочитали тему с обсуждением другой проблемы, ничего не поняли и начали гнуть свою линию...

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

[Nerf]

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

ЧТД

[maleks]

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

Может понадобиться например в таком случае:
Позволено вводить номер телефона 1) только цифры- 0991234567 2) с форматированием - (099)1234567.
Первый валидатор - регулярка проверит ввод общий для обоих.
А фильтром после уже приводить если вариант 1 к варианту 2.

[maleks]

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

Ничего не нарушили, просто вопрос был не в создании своего фильтра, заменяющего три проверки , в yii как раз нет проблем с порядком.
Вопрос был в том что ТС почему то считал что в yii имеется какой то свой специфичный порядок обработки правил (хотя об этом нигде не сказано), поэтому ставя правила-фильтра после правил валидации, получал некорректную работу.

[Nerf]

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

Ничего не нарушили, просто вопрос был не в создании своего фильтра, заменяющего три проверки , в yii как раз нет проблем с порядком.
Вопрос был в том что ТС почему то считал что в yii имеется какой то свой специфичный порядок обработки правил (хотя об этом нигде не сказано), поэтому ставя правила-фильтра после правил валидации, получал некорректную работу.

Как раз таки нарушен SRP. Даже если не вдаваться в пуризм, то решение задачи таким способом приведет к "комбинаторному взрыву". В корне неправильное решение. Сколько таких фильтров нужно создать, чтобы покрыть все комбинации, например, из 5 простых операций?..

[Faenir]

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

ЧТД

Что не так то?

[Леонид]

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

Ничего не нарушили, просто вопрос был не в создании своего фильтра, заменяющего три проверки , в yii как раз нет проблем с порядком.
Вопрос был в том что ТС почему то считал что в yii имеется какой то свой специфичный порядок обработки правил (хотя об этом нигде не сказано), поэтому ставя правила-фильтра после правил валидации, получал некорректную работу.

Как раз таки нарушен SRP. Даже если не вдаваться в пуризм, то решение задачи таким способом приведет к "комбинаторному взрыву". В корне неправильное решение. Сколько таких фильтров нужно создать, чтобы покрыть все комбинации, например, из 5 простых операций?..

Ну я даже не знаю, если очень часто нужно делать одно и то же, то это специфика конкретной реализации того или иного функционала, конкретного проекта. И смена обработки не предвидится, но даже если и будет, то рефакторинг никто не отменял. Так что в контексте моего проекта - это оптимальное решение (100% текстовых инпутов и текстареа в проекте проходят именно такую проверку), естественно если для других членов класса модели требуется другая проверка, то пилю по другому, в смысле юзаю стандартные правила. В конце концов фреймворк - набор часто требующегося функционала. В моём случае понадобилось подогнать под данную специфику, так что с точки зрения фэншуя, да неправильное (если Вы это имели ввиду), а вот с практической точки зрения - очень даже правильное.

По фэншую - не всегда оптимально. Если плюсы превышают минусы (и в перспективе тоже), то нет ничего страшного в том что иногда отходишь от правил. Главное понимать что и для чего делаешь и что в итоге получишь. Имхо. Yii и не заточен под следование по академическому пути.

[zelenin]

не пойму что обсуждаем? что в пхп все работает последовательно и синхронно? а ТС не согласен с этим и хочет чтобы одновременно работало?

[Faenir]

не пойму что обсуждаем? что в пхп все работает последовательно и синхронно? а ТС не согласен с этим и хочет чтобы одновременно работало?

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