СП
Последний пример разве не практично?
['inlineValidation'],просто подключаем
['trim'],
['filter', 'filter' => 'intval'],
['number', 'min' => 9999],
TestRule::classSize: a a a
2020 July 08
СП
Вместо того, чтобы копировать в разные модельки правила
T🐜
Кастомный валидатор создается обычно когда не хватает стандартных.
Ну типа, спец функция, которая что-нибудь вычисляет, и затем сравнивает результат с пришедшими данными.
Тут же просто сгруппировал правила по какому-то критерию, при этом не обозначил цель такой валидации. Т.е. "на всякий случай" буду вот так. Это впоследствии путаницу создаст однозначно.
Ну типа, спец функция, которая что-нибудь вычисляет, и затем сравнивает результат с пришедшими данными.
Тут же просто сгруппировал правила по какому-то критерию, при этом не обозначил цель такой валидации. Т.е. "на всякий случай" буду вот так. Это впоследствии путаницу создаст однозначно.
СП
The Ant 🐜
Кастомный валидатор создается обычно когда не хватает стандартных.
Ну типа, спец функция, которая что-нибудь вычисляет, и затем сравнивает результат с пришедшими данными.
Тут же просто сгруппировал правила по какому-то критерию, при этом не обозначил цель такой валидации. Т.е. "на всякий случай" буду вот так. Это впоследствии путаницу создаст однозначно.
Ну типа, спец функция, которая что-нибудь вычисляет, и затем сравнивает результат с пришедшими данными.
Тут же просто сгруппировал правила по какому-то критерию, при этом не обозначил цель такой валидации. Т.е. "на всякий случай" буду вот так. Это впоследствии путаницу создаст однозначно.
Почему, это будет логически сгрупировано, например
PostNameValidator и там где мне надо будет валидировать название поста - я не буду писать правила, а буду подключать PostNameValidator::classXN
а тогда не проще сделать свой TrimFilterInlineNumber валидатолр?
СП
а тогда не проще сделать свой TrimFilterInlineNumber валидатолр?
Очень не универсально :)
XN
Фишка в том, что можно от такого валидатора наследоваться:
И затем вот так использовать в правилах:
class TestRule extends RuleValidator
{
public $rules = [
['inlineValidation'],
['trim'],
['filter', 'filter' => 'intval'],
['number', 'min' => 9999],
];
public function inlineValidation($attribute, $params, $validator)
{
...
}
}
И затем вот так использовать в правилах:
public function rules()
{
return [
['attr', TestRule::class],
];
}
но это то-же самое
СП
Не тоже самое, делая "TrimFilterInlineNumber" мне придется писать код, а тут я могу использовать конфиг rules
Д
Почему, это будет логически сгрупировано, например
PostNameValidator и там где мне надо будет валидировать название поста - я не буду писать правила, а буду подключать PostNameValidator::classПо-моему реально просто хочется создавать кучу классов. Подклассов. Классов подклассов. И ТД. Ну какой смысл делать новый класс ради группировки 3х правил? Я, например, пришел к вам на проект. Мне ж надо раскопать будет это все. Запомнить.. жесть.
Д
В голове не поместится.
А
Я зашел в небольшой тупик
у меня есть yii\authclient\widgets\AuthChoice widget
и oauth авторизация причем все ссылки вида http://*.loc/auth/oauth?authclient=***
Однако одного из клиентов мне нужно провести через иную ссылку допустим через http://*.loc/auth/service?authclient=sso однако я не пойму как это сделать
у меня есть yii\authclient\widgets\AuthChoice widget
и oauth авторизация причем все ссылки вида http://*.loc/auth/oauth?authclient=***
Однако одного из клиентов мне нужно провести через иную ссылку допустим через http://*.loc/auth/service?authclient=sso однако я не пойму как это сделать
СП
По-моему реально просто хочется создавать кучу классов. Подклассов. Классов подклассов. И ТД. Ну какой смысл делать новый класс ради группировки 3х правил? Я, например, пришел к вам на проект. Мне ж надо раскопать будет это все. Запомнить.. жесть.
Не надо ничего запоминать.
В моделях, где валидируется поле везде будет:
А все правила для валидации поля будут в классе
А вот если правила для валидации НЕ сгруппировать в отдельный класс, то будет дублирование этих правил по всем моделям, где это нужно валидировать.
В моделях, где валидируется поле везде будет:
['name', PostNameRule::class]А все правила для валидации поля будут в классе
PostNameRule.А вот если правила для валидации НЕ сгруппировать в отдельный класс, то будет дублирование этих правил по всем моделям, где это нужно валидировать.
А
Я зашел в небольшой тупик
у меня есть yii\authclient\widgets\AuthChoice widget
и oauth авторизация причем все ссылки вида http://*.loc/auth/oauth?authclient=***
Однако одного из клиентов мне нужно провести через иную ссылку допустим через http://*.loc/auth/service?authclient=sso однако я не пойму как это сделать
у меня есть yii\authclient\widgets\AuthChoice widget
и oauth авторизация причем все ссылки вида http://*.loc/auth/oauth?authclient=***
Однако одного из клиентов мне нужно провести через иную ссылку допустим через http://*.loc/auth/service?authclient=sso однако я не пойму как это сделать
все это выглядит так
Д
Не надо ничего запоминать.
В моделях, где валидируется поле везде будет:
А все правила для валидации поля будут в классе
А вот если правила для валидации НЕ сгруппировать в отдельный класс, то будет дублирование этих правил по всем моделям, где это нужно валидировать.
В моделях, где валидируется поле везде будет:
['name', PostNameRule::class]А все правила для валидации поля будут в классе
PostNameRule.А вот если правила для валидации НЕ сгруппировать в отдельный класс, то будет дублирование этих правил по всем моделям, где это нужно валидировать.
Ну конечно, если размазать форм-модел по куче подклассов то да, будет.
Д
Ну хз вообщем. По мне это избыточно
СП
Ну конечно, если размазать форм-модел по куче подклассов то да, будет.
Форм-модел как раз никуда размазывать не надо. На каждый вход данных своя форм-модел.
Например:
Создание статьи
Редактирование только названия статьи
Редактирование полностью статьи
Изменение наззвания статьи по апи
Например:
Создание статьи
Редактирование только названия статьи
Редактирование полностью статьи
Изменение наззвания статьи по апи
a
Ну конечно, если размазать форм-модел по куче подклассов то да, будет.
ворвусь и я
a
размазывание dto и классов работы с ними это иногда удобно
СП
atcq (Алексей)
размазывание dto и классов работы с ними это иногда удобно
на развивающихся проектах - очень
a
не только