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

[Bio man]

Никого не смущает то, что в методе rules() валидаторы и фильтры собраны в 1 кучу?
Ведь по идеи валидаторы должны читать атрибуты, но не изменять их значения.

Почему бы не разделить это добро на 2 логических группы:
1. Валидаторы - проверяют атрибуты на соответствие бизнес-правилам, не могут изменять атрибуты
2. Фильтры - обрабатывают атрибуты по каким-то бизнес-правилам, могут изменять атрибуты в соответствии с правилами (например, существующий "валидатор" default является фильтром)

Есть в этом смысл или я опять бред несу?

Спасибо.

[mickgeek]

Когда-то обсуждали нечто подобное.

viewtopic.php?f=19&t=19209

[samdark]

Тогда не получится применять их в определённом порядке.

[Bio man]

Ну а если как-то так сделать?

Код: Выделить всё

    public function rules()
    {
        return [
            ['text', 'required', 'before' => 'purify'], // before filter named 'purify'
            ['status', 'integer', 'after' => 'default'], // after all default filters
        ];
    }

    public function filters()
    {
        return [
            'purify' => ['text', 'purify'], // inline filter
            ['status', 'default', 'value' => 1],
        ];
    }

[samdark]

Зачем так усложнять?

[zelenin]

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

[yiijeka]

было. Всё оставили как есть, но все высказались, что не совсем корректно всё хранить вместе.

[samdark]

С одной стороны не совсем корректно, с другой разделение всё страшно усложняет: иногда надо выполнять фильтрацию после валидации или в процессе валидации.

[zelenin]

С одной стороны не совсем корректно, с другой разделение всё страшно усложняет: иногда надо выполнять фильтрацию после валидации или в процессе валидации.

без примеров довод не принимается.

[creocoder]

С одной стороны не совсем корректно, с другой разделение всё страшно усложняет: иногда надо выполнять фильтрацию после валидации или в процессе валидации.

без примеров довод не принимается.

Вот конкретный пример:

Код: Выделить всё

    /**
     * @inheritdoc
     */
    public function rules()
    {
        return [
            ['name', 'filter', 'filter' => 'trim'],
            ['name', 'required'],
            ['name', 'string', 'max' => 255],

            ['email', 'filter', 'filter' => 'trim'],
            ['email', 'required'],
            ['email', 'email'],
            ['email', 'string', 'max' => 255],
            [
                'email',
                'unique',
                'targetClass' => 'common\models\UserEmail',
                'targetAttribute' => 'value',
                'message' => 'This email address has already been taken.',
            ],

            ['password', 'required'],
            ['password', 'string', 'min' => 6],
        ];
    }

Чтобы что то куда то делить, нужны веские основания. У вас они есть?

[samdark]

Кстати, не нашёл прошлых обсуждений...

[yiijeka]

viewtopic.php?f=19&t=19209&hilit=default

[samdark]

О, вот там и примеры нашлись. Тот же HTMLPurifier...

[zelenin]

С одной стороны не совсем корректно, с другой разделение всё страшно усложняет: иногда надо выполнять фильтрацию после валидации или в процессе валидации.

без примеров довод не принимается.

Вот конкретный пример:

Код: Выделить всё

    /**
     * @inheritdoc
     */
    public function rules()
    {
        return [
            ['name', 'filter', 'filter' => 'trim'],
            ['name', 'required'],
            ['name', 'string', 'max' => 255],

            ['email', 'filter', 'filter' => 'trim'],
            ['email', 'required'],
            ['email', 'email'],
            ['email', 'string', 'max' => 255],
            [
                'email',
                'unique',
                'targetClass' => 'common\models\UserEmail',
                'targetAttribute' => 'value',
                'message' => 'This email address has already been taken.',
            ],

            ['password', 'required'],
            ['password', 'string', 'min' => 6],
        ];
    }
 

Чтобы что то куда то делить, нужны веские основания. У вас они есть?

пример чего? что тримится должно перед валидацией? да, так и должно быть, но ПЕРЕД валидацией, а не в начале валидации.
Основания: валидация не должна изменять данные. Она должна выплюнуть ошибку. А тримы замечательно запихнуть в поведения на BEFORE_VALIDATE, используя тот же AttributeBehavior

[zelenin]

О, вот там и примеры нашлись. Тот же HTMLPurifier...

так ради бога (см. выше). Если надо до валидации или после есть поведения.

[samdark]

И как это будет выглядеть в поведении в сравнении с тем, как это выглядит сейчас? Уложится в одну строчку?

[zelenin]

И как это будет выглядеть в поведении в сравнении с тем, как это выглядит сейчас? Уложится в одну строчку?

Александр, я привел довод: валидация должна валидировать. Причем тут "как это будет выглядеть в поведении в сравнении с тем, как это выглядит сейчас"? Мы же правильность обсуждаем.

да и выглядеть это будет не сильно сложно:

Код: Выделить всё

[
'class' => 'TrimBehavior',
'attributes' => [...]
]
 

или

Код: Выделить всё

[
'class' => 'AttributeBehavior',
'attributes' => ['content'],
'value' => function(Event $event) {return trim($event->sender->content}, //ну или как там - не суть, можно запилить поведение для обработки функциями типа trim итд
]
 

[mickgeek]

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

[samdark]

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

Пример creocoder выше дал простенький. Если туда добавится default, htmlpurifier и ещё пара типов фильтрации, то в случае с behavior-ами:

1. Кода писать надо будет больше.
2. Выглядит это объективно сложнее.
3. Behavior работает несколько медленней.

Даже если вместо rules() сделать validationRules() и filteringRules() кое-что теряется. А именно возможность иметь рядом правила для поля, а не бегать между методами, чтобы понять, что происходит.

Но на интересную мысль, кстати, навели. Метод у нас называется rules(), так что можно поменять гайд и описание и везде заменить "validation rules" на "filtering and validation rules".

[zelenin]

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

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