MVC и валидация

[MiksIr]

А в реальности посмотри на связки "модель формы" + "модель базы", к чему твой fieldset стремится. Не получается такого, что он фактически равен модели базы и лишь модель формы его расширяет?

 

[fixxxer]

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

 

[WMix]

fixxxer
тоже подход, а формуляр по индексам собираешь типа? а куда сами элементы складываешь что то текст а это селест итд?

 

[MiksIr]

Просто исходим из реальности. Данные обычно куда-то кладутся. Этим занимается модель базы (ну или модель rpc или еще что-то, но в общем конечная модель). Ее валидатор априори должен исполняться. Коллекция моделей... ну тут не знаю как используешь, но судя по тому, что я понимаю коллекцией... тут валидатор скорее на состояние моделей в коллекции, т.е. он никак не пересекается с валидатором модели, хотя может его вызывать. Далее, модель входных данных... ее задача переварить вход и подготовить для вывода в конечную модель. Т.е. там валидаторы всех конечных моделей, куда эта входная рассовывает данные плюс специфичные валидаторы для входа.
Дополни картину
Т.е. я даже понимаю в чем-то прелесть выноса валидатора... но в общем это такой вопрос... вкуса что ли, а не реальной необходимости. Может ошибаюсь.

Но вообще я сейчас понял, что да, нужно прикрутить что-то к Yii для подключения в валидатор формы валидаторов модели =) Хотя последнее время я использую валидаторы формы для генерации html формы )

 

[WMix]

CollectionModel это и есть класс форма только поfixxxerная

 

[fixxxer]

WMix
А нету хтмлных терминов, есть абстрактные Scalar, Select, Multiselect, Boolean...
В какую html-ку рендерить определяет вьюха. Какая остальному коду разница, радиобаттоны или селект там в хтмле?

 

[fixxxer]

MiksIr
ну ведь не всегда данные приходят из формы. Есть внутренние RPC, которые берут json и пуляют прямо в модель. Для них формы-валидаторы городить совсем не хочется, но и чтобы невалидный e-mail прилетел, не хочется тоже. Так что я хочу, чтобы модель таки проверяла все, что может проверить.

Двойной проверки не будет - у полей есть isTainted, а fieldset может работать в dirty/trusted datasource mode.

 

[WMix]

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

Scalar, Select, Multiselect, Boolean

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

 

[MiksIr]

Да пусть будет входная модель, почему нет. Ничем не сложнее
А емейл как CONSTRAINT CHECK на поле в базе =))))

 

[vanicon]

Есть модель пользователя, со всеми понятными полями.
Теперь у нас есть форма регистрации, где есть
1) поле "повторный ввод пароля",
2) капча.

Куда девать эти поля? Дублировать поля и валидации в форме - нехорошо, пихать password2 и (омг) капчу в UserModel - тоже нехорошо.

Я его решил, но вы меня назовете оверинженерастом

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

 

[fixxxer]

Пример затруднит, там много, чистить от зависимостей и оформлять как самостоятельную либу влом, да и не важна тут конкретная реализация =)

Вкратце я описал тут - в этом суть, все остальное можно сделать как угодно, вариантов миллион.

 

[stwa]

Я использую такой подход:
1. Модели бывают разные, есть модель предметной области, а есть "инфраструктурные" модели, пусть это будут User и UserForm
2. Все валидаторы входных данных в UserForm. В User нет никаких валидаторов, только бизнес-логика
3. Все данные, которые должна получить модель предметной области User (не важно откуда они - post, RPC, console и т.д.) направляются сначала в "инфраструктурную" модель UserForm для валидации.
4. У UserForm есть все возможные валидаторы, которые могут быть связаны с User, включая captcha, passwordVerify и т.д. Также у UserForm есть метод setValidationGroup, который позволяет указать какие валидаторы использовать в том или ином случае.
5. Для удобства у UserForm есть метод bind, который "сбросит" данные в модель предметной области (User), если валидация будет успешно пройдена.

 

[Absinthe]

3. Все данные, которые должна получить модель предметной области User (не важно откуда они - post, RPC, console и т.д.) направляются сначала в "инфраструктурную" модель UserForm для валидации.

А почему вторая модель называется Form, если она не связана с формами?
И почему бы валидацию модели не перенести в User?
Что будет, если ты забудешь данные валидировать через Form и отдашь в User?

 

[WMix]

stwa
ну вроде так и должно быть, но это не так красиво как описал, если форма манипулирует несколькими моделями (заказ и позиции заказа), то как называем?, логика если повторная позиция увеличиваем счетчик, если выбрана доставка АБЦД то появляется новая позиция, цена доставки.
fixxxer
а в твоем подходе, где находятся ошибки валидации? "Имя пользователя должно состоять только из букв и должно быть длиной минимуи 5 символов"

 

[vanicon]

stwa, ваш подход мне не очень нравится, потому что пользователь в системе одни и правила для них одинаковые (неважно как будет происходить регистрация, через форму или еще как), а в вашем подходе нужно будет прописывать одни и те же правила для валидации логина и пароля, и когда регистрация будет происходить через форму или еще как нибудь...
Вот над каким подходом я подумал, есть модель user у нее есть свойства типа логина, мыла и тд.
Там в статическом методе рулес прописываются все правила, но только для свойств этой модели...
А поля типа капчи и повтора пароля будут описываться в модели формы, но только эти правила, правила для логина и других свойств сущности не дублируются туда...
В контроллере вызываем вспомогательный класс и передаем туда два объекта, модель формы и модель пользователя, а также данные, этот класс соберет все правила проверок в единое и отвалидирует,
и если все ок он может вернуть валидный объект пользователя, в общих чертах как-то так...

 

[stwa]

Одна HTML-форма может содержать в себе данные из многих инфраструктурных моделей, равно как и post-данные, пришедшие в одном пакете не обязательно все целиком должны относиться к одной модели. Кто мешает вам в контроллере разобрать post-запрос и разложить его по нескольким моделям?

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

 

[stwa]

vanicon
не понял что вы имели ввиду.
у меня как раз механизм валидации не зависит от того, откуда пришли данные из HTML-формы или еще откуда
единые правила для всех способов
кроме того методом setValidationGroup я могу гибко управлять этими правилами, например отключить валидацию passwordVerify, если мы генерируем пароль сами.

 

[vanicon]

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

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

 

[vanicon]

у меня как раз механизм валидации не зависит от того, откуда пришли данные из HTML-формы или еще откуда
единые правила для всех способов

Можно пример небольшой, реализации идеи?

 

[fixxxer]

fixxxer
а в твоем подходе, где находятся ошибки валидации? "Имя пользователя должно состоять только из букв и должно быть длиной минимуи 5 символов"

Это view логика, отображение текста ошибки по ее коду. У меня intl работает не как gettext, а с регистрацией кодовых имен сообщений; код ошибки совпадает с именем сообщения.
Для одноязычной системы придется городить {% if input.error == 'bla' %}bla{% endif %} или карту прямо в шаблоне, не очень удобно, согласен. Хотя макросами решается.