Yii Framework

Этот вопрос относится и к первой версии.
Зачем он нужен, валидатор "default".
Ведь установку атрибутов по умолчанию нужно делать не во время валидации,
а чтоб эти значения были уже после создания.
Соответственно устанавливать их надо в конструкторе или методе "init()"

Ваши мысли? Может есть use cases где они нужны?

а сценарии

я null выставляю через этот валидатор, тем атрибутам, которые DEFAULT NULL, т.к. при создании модели, если поля не заполнены в форме, то у меня в бд пишется "" - пустота, а не NULL, почему то.

Да уж, немного странный валидатор, который ничего не валидирует

Может быть и полезен иногда, но почему это валидатор - не понятно.
Можно ведь это и в init / beforeSave / afterFind или в любом другом подходящем событии указать...

yiijeka, https://github.com/yiisoft/yii2/blob/3a ... d.php#L106

yiijeka писал(а):я null выставляю через этот валидатор, тем атрибутам, которые DEFAULT NULL, т.к. при создании модели, если поля не заполнены в форме, то у меня в бд пишется "" - пустота, а не NULL, почему то.

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

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

FilterValidator - это другое, фильтрация и валидация нераздельная часть. До валидации, нам нужно значения отфильтровать и и подготовить к этой самой проверке.

А вот установка значений по умолчанию, это совсем не относится к процессу валидации. ИМХО.
Звучит странно "атрибут будет иметь значение по умолчанию если пройдет валидацию", а если не нужно запускать валидацию?

Может функционал нужный, просто название неподходящее?

Model::init(), кстати, не очень подходящее место для этой цели. Например, если ModelSearch будет унаследована от этой модели, то для корректной работы нам так же придётся переопределять ModelSearch::init().

Это вообще другая песня, PostSearch extends Post, это то что вызывает у меня очень некрасивые слова.

slavcodev писал(а):FilterValidator - это другое, фильтрация и валидация нераздельная часть.

Я имел в виду, что FilterValidator тоже не является валидатором в принципе.

slavcodev писал(а):Это вообще другая песня, PostSearch extends Post, это то что вызывает у меня очень некрасивые слова.

Согласно документации, так делать вполне нормально. А уж тем более, какой смысл дублировать атрибуты в классе, когда они уже есть в другом?

mickgeek писал(а):Согласно документации, так делать вполне нормально. А уж тем более, какой смысл дублировать атрибуты в классе, когда они уже есть в другом?

Не будем об этом, ужж точно в этой теме.

Насчёт того, что я выставлял через него null это "не профессионально" конечно же, надо же было как то его попробовать :) На loadDefaultValues как то не обратил внимание, в своё время.

У меня вообще валидаторы trim и default вызывают непонимание, что они делают в ВАЛИДАТОРАХ, которые по сути должны только валидировать, а не изменять. Их нужно в beforeSave перенести или использовать как TimestampBehavior например. Может issue по этому поводу создать? Типа валидаторы должны проверять, а не изменять значения.

yiijeka писал(а):Может issue по этому поводу создать? Типа валидаторы должны проверять, а не изменять значения.

Создатели знают об этом. В документации написано, что эти валидаторы вовсе и не валидаторы. Но можно, конечно, создать Issue для уточнения, почему так сделано.

https://github.com/yiisoft/yii2/issues/4645 поддержите кто за.

Мне наоборот не сильно нравится что например валидатор 'integer' не преобразует строку с числом (поступившим из формы) в целочисленный тип. Присваивание то в основном массовое, с атрибутами отдельно не работаем.

хм, т.е. если у вас поступает из формы "2" и вы хотите, чтобы это было (int) 2 ? Зачем?

По мне так проверять (валидировать), это означает проверить и вернуть boolean результат - либо прошло проверку, либо не прошло. Если я пускаю в валидатор значение например "2.2", то жду от него boolean - false (нет это не integer) и не как не true ((int) 2) - это ломает смысл всего валидатора. А такие преобразования должен делать "конвертатор", а не валидатор.

Да нет же, фильтры относятся к проверке данных (валидации), они есть везде, в ZF например. Хотя для фильтров там отдельный класс сделан и отдельная цепочка. Но она тоже срабатывает в моменнт валидации ($model->isValid()). Думаю вас смущает название, что фильтр наследует Validator, но это сделано из практических соображений, с этим просто нужно смерится, и принимать фильтры как фильтры а не валидаторы. Но убирать их в другое место не нужно. Они всегда идут совместно с валидацией. Сначал фильтруете данные, готовите к проверке и потом сразу проверяете. Отдельно делать либо фильтрацию либо валидацию, никогда не нужно.

maleks писал(а):Мне наоборот не сильно нравится что например валидатор 'integer' не преобразует строку с числом (поступившим из формы) в целочисленный тип.

И тут все ок. Валидатор должен проверять, а не изменять значение. Хотите изменять используйте фильтры

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

['attr', 'filter', 'filter' => 'intval']

Это понятно, что фильтры привязаны в некотором смысле к валидации, но пихать их все вместе в rules как то путает. Было бы не плохо фильтры в одно место, валидаторы в другое. А то нужно следить, чтобы фильтры были всегда первее валидаторов.

Иногда надо лишь после успешной валидации фильтровать. Например, прогонять текст HTMLPurifier.

Yii Framework

Default Validator

Default Validator

Re: Default Validator

Re: Default Validator

Re: Default Validator

Re: Default Validator

Re: Default Validator

Re: Default Validator

Re: Default Validator

Re: Default Validator

Re: Default Validator

Re: Default Validator

Re: Default Validator

Re: Default Validator

Re: Default Validator

Re: Default Validator

Re: Default Validator

Re: Default Validator

Re: Default Validator

Re: Default Validator

Re: Default Validator