разделить rules на 2 части

[samdark]

zelenin, ОК, допустим мы захотим разделить (хоть и не вижу я особо профита). Почему именно behavior? Варианты:

1. behavior.
2. afterValidate().
3. Новый метод filters.
4. Два новых метода: validationRules, filterRules.
5. ...

И ещё вопрос на тему default остаётся. Фильтр это или валидатор?

[creocoder]

а как же единая ответственность?) зачем документально фиксировать ошибку в проектировании, если можно в в 2.0.* добавить еще одно поведение, а в 2.1 удалить defaultValidator и filterValidator?

Давайте не будем притягивать за уши умные слова из SOLID про единую ответственность (SRP) и прочее. Метод `rules()` это сервисный метод, где перечисляются правила фильтрации и валидации. Это просто список. Никакого нарушения SRP в нем нет!

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

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

Во-первых надо руководствоваться хотя бы минимальной (!) правильностью.

Всё и ТАК правильно. У нас валидация валидирует и не меняет значения. То что правила валидации и фильтрации в виде списка живут в одном месте, так это из практических соображений. И это ничего не нарушает абсолютно.

@sam_dark Я предлагаю в 2.1 сделать следующее. Во первых переместить `\yii\validation` в `\yii\rules`. А фильтры выделить в отдельное понятие `Filters` со своим базовым классом. И тогда точно никакой путаницы не будет.

[zelenin]

zelenin, ОК, допустим мы захотим разделить (хоть и не вижу я особо профита). Почему именно behavior? Варианты:

1. behavior.

это уже работает. У многих висит там уже какая-то фильтрация/трансформация - слагифай, транслит, нормализация юникода, пурифай итд итп.

2. afterValidate().

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

3. Новый метод filters.
4. Два новых метода: validationRules, filterRules.
5. ...

уже появились attributeHints - ужас. Зачем плодить новую сущность?

И ещё вопрос на тему default остаётся. Фильтр это или валидатор?

третье


а по мне так было бы нормально и вообще поведения убрать, как планируется, но это будет потрясение для нежных девелоперов.

[zelenin]

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

это неконструктивный диалог, когда вы подменяете понятия. Показали изменения трех строчек на три строчки (71 символ на 140 символов). Объективно уменьшилось удобство? Такой манерой диалога вы навязываете свое мнение.

[creocoder]

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

это неконструктивный диалог, когда вы подменяете понятия. Показали изменения трех строчек на три строчки (71 символ на 140 символов). Объективно уменьшилось удобство? Такой манерой диалога вы навязываете свое мнение.

Неконструктивный диалог это когда вы тащите в качестве аргументов SRP не понимая до конца что это такое и что применить это к методу `rules()`, который отдает просто список это бред сивой кобылы. Метод `rules()` с позиции SRP корректный на 100%, потому что он выполняет единственную задачу "отдать список".

Неконструктивный диалог это когда вы заявляете, что "Валидация должна валидировать" и не понимаете что `rules()` как список бизнес правил к процессам валидации имеет лишь крайне косвенное отношение.

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

[zelenin]

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

это неконструктивный диалог, когда вы подменяете понятия. Показали изменения трех строчек на три строчки (71 символ на 140 символов). Объективно уменьшилось удобство? Такой манерой диалога вы навязываете свое мнение.

Неконструктивный диалог это когда вы тащите в качестве аргументов SRP не понимая до конца что это такое и что применить это к методу `rules()`, который отдает просто список это бред сивой кобылы. Метод `rules()` с позиции SRP корректный на 100%, потому что он выполняет единственную задачу "отдать список".

Неконструктивный диалог это когда вы заявляете, что "Валидация должна валидировать" и не понимаете что `rules()` как список бизнес правил к процессам валидации имеет лишь крайне косвенное отношение.

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

ок, я понял вашу позицию. Все что происходит между событиями BEFORE_VALIDATE и AFTER_VALIDATE - это не только валидация, а еще и некие бизнес-правила. Валидаторы не только валидаторы, но и фильтры, а также сущности, устанавливающие дефолтные значения. Что доки в разделе валидации описывают не только валидацию. А тема создалась (не первый раз) потому что (100% - 1) пользователей не в курсе, что происходит в методе Model::validate(). Вы победили)

[zelenin]

про srp я конечно ошибся, приведя в пример rules(), который отдает массив. Жаль, что вы не поняли, что имелся в виду процесс валидации в целом, а в частности Model::validate(). Это так удобно в споре играться с чужими словами.

[zelenin]

все, что я перечислил нужно будет тоже менять с *validate* на *businessRulesHandle* иначе через полгода третий раз будем это обсуждать. В итоге вместо валидации, присутстсвуующей везде, мы будем применять набор бизнес правил разного вида (валидация, фильтрация, присваивание). Ок.

[samdark]

ОК. Почему именно behavior понятно. На 2.1 точно стоит обдумать. Beavior-ы в пользу trait-ов + even-ов, скорее всего, будем выкидывать.

[lynicidn]

для меня рулесы, это посл действий по сценарию, правила сценария, мне пофиг че в них, валидация или какая другая логика, открыв их, я вижу что происходит по сценарию, какая последовательность, то что она запускается $model->validate или бы обрабатывалась в beforeValidate без разницы - это скрытая логика. Разделение этого на 2 части это большое ломание совместимости, т.к. надо будет переписывать scenarios метод, который бы теперь строил "карту" на основе 2х методов, особо профита тоже в этом не вижу

[ElisDN]

делаем еще одно поведение, куда передаем атрибуты и колбэки функций - все остается в таком же (!) виде, как и в валидации, только добавляется класс поведения.

Так уже можно с AttributeBehavior замутить.

[zelenin]

делаем еще одно поведение, куда передаем атрибуты и колбэки функций - все остается в таком же (!) виде, как и в валидации, только добавляется класс поведения.

Так уже можно с AttributeBehavior замутить.

я об этом писал выше.