ну я смотрю по коду что там перебираются валидаторы

в rules, насколько я понимаю, каждый элемент массива - отдельный валидатор

если валидатор вернул false (атрибут не валиден), можно-ли на этом месте прервать валидацию?

а смысл? пусть уже добьет до конца и не пропустит дальше действие в любом случае

предположим что дальше по коду ещё, например, 10 проверок с обращением к БД, и я хотел-бы их избежать

наверное, только наследовать ActiveRecord и реализовывать свой validate() с блэкджеком

а что если использовать разные сценарии? сначала один, где валидируется только один параметр, если true - то другой зарядить, где будет проверяться все остальное

наверное во время валидации подмена сценария не даст никакого эфекта

ибо там в validate() идёт ->getActiveValidators(), в котором валидаторы выбираются по сценарию

мы ж будем продолжать валидировать по первому сценарию :)

наверное во время валидации подмена сценария не даст никакого эфекта

после валидации новую модель создать с новым сценарием, и $model->load заполнить ее

да проще чем такое разводить модельку унаследовать :D

я просто думал что уже реализовано, дабы не велосипедить

если валидатор вернул false (атрибут не валиден), можно-ли на этом месте прервать валидацию?

skipOnError же

в доке по skipOnError немного другое пишут

правило не будет применяться если для этого поля уже существует ошибка

хотя

хм

можно нагородить и так

все же я думаю, что подмена сценария должна сработать)

можно просто все правила валидации под одно поле запилить, и skipOnError но в идеале хотелось-бы получить вариант обрыва всех сценариев валидации на определённом месте

1. Сделать сценарий с валидацией первого поля 2. Если нет ошибки - подменяем сценарий, в котором проверяем все остальное, и опять валидируем

1. Сделать сценарий с валидацией первого поля 2. Если нет ошибки - подменяем сценарий, в котором проверяем все остальное, и опять валидируем

если нам нада сделать 40 проверок, из них 20 по сценарию "дальше не идем" будешь 20 сценариев делать? ;D

если нам нада сделать 40 проверок, из них 20 по сценарию "дальше не идем" будешь 20 сценариев делать? ;D

Надо нормальную логику делать в таком случае

да и так нормльная логика. все ошибки сразу подсветит

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

да понятное дело что свою писать :) я ж спрашивал есть-ли что готовое

И вообще, это получается схема самого ужасного интерфейса. Где форму заполнить можно с 40 раза пока все поля отдельно пошагово пройдешь с этими прерывистыми валидпторами

надо добавить в /yii/validators/Validator поле dieIfError, и одну дополнительную проверку в Model->validate(), и вопрос решён :)

сделать вместо формы мастер

и на каждом этапе проверять в своей модели

да понятное дело что свою писать :) я ж спрашивал есть-ли что готовое

Можно вам в лицо плюнуть? , всегда хотел найти людей, из-за которых над одной формой сидишь 30 минут, а потом оказывается, что на последнее поле ты не знаешь чем заполнить т.к. у тебя нет представления чем это заполнить

надо добавить в /yii/validators/Validator поле dieIfError, и одну дополнительную проверку в Model->validate(), и вопрос решён :)

потом дрочить юзера по одной ошибке на 40 полях чтоб исправлял. збс идея, мне нравится ))

Делите форму на стейджи в конце концов

нет валидация у меня происходит в API моя задача - реализовать "на новый лад" одно старое API данные в API идут как POST, + там есть поле data с xml'кой внутри

вот для этой xml'ки валидацию я и делаю

Это же сколько раз нужно сабмитить форму, чтобы правильно заполнить поочередно 40 полей?

если пользователь забанен, смысл проверять, были-ли от него ещё какие-то сущности?

Дмитрий, вы будто недавно налоговую декларацию онлайн заполняли. откуда столько страсти? :D

Забанен ли пользователь у вас должен проверять аут менеджер или рбак

пользователь забанен, всё, баста пиши в поддержку, спрашивай почему

Забанен ли пользователь у вас должен проверять аут менеджер или рбак

я ж уточнил, что валидация для данных внутри xml'ки

И давать код 403

я не хочу сейчас расписывать всех особенностей реализации системы, просто оно должно вернуть одну единственную ошибку если пользователь забанен

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

сколько логики?

вы мою модель видели?

я здесь за один валидатор спросил

Дмитрий, вы будто недавно налоговую декларацию онлайн заполняли. откуда столько страсти? :D

Да не) просто пытаюсь наставить на пусть истинный)

за существование в фреймворке из коробки необходимого функционала

я никакого кода не предоставлял

у меня есть повторяющаяся в многих местах модель пользователя - Consignee, которому будет отправлена (допустим) посылка вот этого пользователя нужно валидировать тот кто отправляет посылку уже давно провалидирован

я здесь за один валидатор спросил

Загрузил человек xml, окей. Тут вы дали ошибку, что поле неверное, он его исправил. Далее по кругу и каждый раз нужно будет ему править его под каждое поле отдельно, вместо того, чтобы один раз увидеть все ошибки и быстро все поправить

если пользователь забанен, смысл проверять, были-ли от него ещё какие-то сущности?

если он забанен, почему API вообще что-то проверяет) Можно узнать, забанен или нет и без валидации

ERROR: S client not available

для остальных полей всё работает так как вы сказали

да ёб

ладно

смысл здесь срач разводить

спасибо

если он забанен, почему API вообще что-то проверяет) Можно узнать, забанен или нет и без валидации

Я о том же

я выше отписал

у меня есть повторяющаяся в многих местах модель пользователя - Consignee, которому будет отправлена (допустим) посылка вот этого пользователя нужно валидировать тот кто отправляет посылку уже давно провалидирован

вы всей архитектуры не знаете, и уже каждый со своим решением лезет наставлять на путь истинный

В данной реализации yii всё так как реализовано - реализовано не просто так. Кмк вы заведомо уже на ложном пути. Пересмотрите бизнес логику вашего приложения.

вы всей архитектуры не знаете, и уже каждый со своим решением лезет наставлять на путь истинный

в итоге и будет решение из 40 шагов с сотней условий в валидаторах

эт если сделать по вашей логике с сценариями

Я уверен, что все можно сделать проще

конечно

можно вообще с нуля написать всё

но только существующие клиенты охуеют

переписывать всё под новый формат входных данных

эт если сделать по вашей логике с сценариями

Ознакомьтесь с ООП и solid, мне кажется чет у вас там наговнокодено)

эт если сделать по вашей логике с сценариями

ну так они для того и придуманы, чтобы под разные условия проверять. А если там есть 40 шагов, на половине из которых надо дальнейшую валидацию отменять, то я уже выше сказал, что логика у вас неправильная (на мой взгляд). я не знаю, что у вас за приложение

переписывать всё под новый формат входных данных

И прошу прощения за резкость)

ну так они для того и придуманы, чтобы под разные условия проверять. А если там есть 40 шагов, на половине из которых надо дальнейшую валидацию отменять, то я уже выше сказал, что логика у вас неправильная (на мой взгляд). я не знаю, что у вас за приложение

На мой также

но только существующие клиенты охуеют

вам надо валидировать содержимое XML?

вам надо валидировать содержимое XML?

да

да ладно, забейте

я тут больше с вами переписываюсь чем свой "говнокод" пишу

?