Вот у меня в этом месте нерешённый трабл. Я согласен что модель должна знать как валидировать и как фильтровать, но я считаю что она эти данные должна рассказывать лишь форме.
-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
Сеттеры в PHP
- Автор темы Василий М.
- Дата начала
Redjik
Джедай-мастер
Почему?
В модель кто-угодно обращается - она огрызается валидацей, она не знает кто обратился, просто дает feedback на действие - все логично...
AmdY
Не, форме пофигу. А модель берет из нее только то, о чем знает. Хитрость в том, что поля (и их валидаторы и фильтры) у формы и модели в результате вызова fillFromModel - одни и те же (в буквальном смысле: один и тот же объект).
Соответственно, можно добавить в форму, например, капчу, и она никому не помешает.
То, как ломали гитхаб, тут тоже сработает - ведь форма получит вообще все поля. При этом, в каких-то случаях эти поля в форме нужны, а в каких-то - нет. Это нужно решать через ACL (я сейчас вообще теоретизирую, у меня это все сделано через одно место). Плюс, наверное, надо разделять поля на "публичные" и "приватные": некоторые поля, присутствующие в базе, вообще не надо видеть снаружи - например, флажок is_deleted какой-нибудь.
Магических методов в моем примере нет вообще. Возможность засунуть какие угодно поля я считаю минусом
Не, форме пофигу. А модель берет из нее только то, о чем знает. Хитрость в том, что поля (и их валидаторы и фильтры) у формы и модели в результате вызова fillFromModel - одни и те же (в буквальном смысле: один и тот же объект).
Соответственно, можно добавить в форму, например, капчу, и она никому не помешает.
То, как ломали гитхаб, тут тоже сработает - ведь форма получит вообще все поля. При этом, в каких-то случаях эти поля в форме нужны, а в каких-то - нет. Это нужно решать через ACL (я сейчас вообще теоретизирую, у меня это все сделано через одно место). Плюс, наверное, надо разделять поля на "публичные" и "приватные": некоторые поля, присутствующие в базе, вообще не надо видеть снаружи - например, флажок is_deleted какой-нибудь.
Магических методов в моем примере нет вообще. Возможность засунуть какие угодно поля я считаю минусом
Угу, так и есть
Absinthe
жожо
В гитхабе была допущена ошибка массового присваивания. Это та же ошибка, что и "экранируем значения перед запросом" или "отсутствие автоэкранирования всего в отображении"(!!!).
А я вот уверен, что некоторые отписавшиеся в этой теме, не считают это ошибкой.
Я считаю это ошибкой однозначно.
Рельсы с такой ошибкой прекрасно справляются из коробки раскоментированием 1 строки в конфиге, но гитхабовцы это не сделали.
С чего бы?
Absinthe
То, что это ошибка, это бесспорно. Вопрос в том, как должен быть устроен фреймворк, чтобы ошибок такого рода избегать средствами собственно фреймворка.
Строка в конфиге - это совершенно неочевидно; то, что по умолчанию разрешается все - это вообще неправильно (должно быть наоборот). Более того, нередка ситуация, когда в одном контексте какое-то поле допустимо присваивать, в другом - нет.
То, что это ошибка, это бесспорно. Вопрос в том, как должен быть устроен фреймворк, чтобы ошибок такого рода избегать средствами собственно фреймворка.
Строка в конфиге - это совершенно неочевидно; то, что по умолчанию разрешается все - это вообще неправильно (должно быть наоборот). Более того, нередка ситуация, когда в одном контексте какое-то поле допустимо присваивать, в другом - нет.
Хорошо, кому, кроме формы (и самой модели), надо это знать, и зачем?
Absinthe
жожо
Это очевидно, т.к. об этом сразу пишут в документации и гайдах.
Если не указать attr_accessible в модели, то не даст сделать массовое присваивание.
Роли в контексте attr_accessible и методов массового присваивания. Из коробки.
fixxxer любым источникам данных модели. Почему это при вводе с формы модель должна быть валидной, а при получении из файла/сети - нет?
Это само собой. Невалидированное обязательно перед сохранением провалидируется вне зависимости от. Самой моделью.
Вообще вы все меня провоцируете взять свои наработки, привести в божеский вид, дописать и отрефакторить все, что давно хотел, и выложить на какой-нибудь гитхаб.
Вообще вы все меня провоцируете взять свои наработки, привести в божеский вид, дописать и отрефакторить все, что давно хотел, и выложить на какой-нибудь гитхаб.
Absinthe
В простейшем случае, когда поля формы - подмножество полей модели, да.
Проблемы начинаются, когда добавляешь, скажем, капчу на страницу регистрации пользователя. В модели пользователя капче совершенно точно делать нечего.
UPD - только что подумал: возможно, имеет смысл для такой вещи отнаследоваться от модели пользователя. Тогда действительно все как ты говоришь.
В простейшем случае, когда поля формы - подмножество полей модели, да.
Проблемы начинаются, когда добавляешь, скажем, капчу на страницу регистрации пользователя. В модели пользователя капче совершенно точно делать нечего.
UPD - только что подумал: возможно, имеет смысл для такой вещи отнаследоваться от модели пользователя. Тогда действительно все как ты говоришь.
Absinthe
жожо
Не обязательно.
Смотри, как можно.
Форма отрисовывается в отображении, основываясь данными на модели или объекте модели.
При запросе модели передаются поля формы, и она их массово принимает. А в контроллере проверяется капча.
Если модель не провалидировалась, то отдает форме сообщения об ошибках.
При этом валидация в самой форме отсутствует. Она разделена по модели (проверки, связанные с данными) и контроллеру (проверки, связанные с протоколом). И форма сама является объектом отображения и не лезет в модель и контроллер, где управятся без нее.
В итоге получаем чистое и понятное MVC.
То есть, вообще в форму капчу не добавлять?
Тогда придется писать руками все: получение значения капчи, в шаблоне руками поле вместо вызова макроса для формы...
Не, мне это не нравится, лучше в форме это иметь.
Давай рассмотрим другой случай: ввод пароля дважды при регистрации. Вот тут, мне кажется, как раз с наследованием наиболее уместно: мы, по хорошему, вообще не должны где-то в контроллере хотеть знать, что поле называется password.
Тогда придется писать руками все: получение значения капчи, в шаблоне руками поле вместо вызова макроса для формы...
Не, мне это не нравится, лучше в форме это иметь.
Давай рассмотрим другой случай: ввод пароля дважды при регистрации. Вот тут, мне кажется, как раз с наследованием наиболее уместно: мы, по хорошему, вообще не должны где-то в контроллере хотеть знать, что поле называется password.
Справится-то справится, но:
1) это поле нужно в одном частном случае, и вряд ли является логикой модели пользователя - все же это скорее view-логика, ведь это поле нужно исключительно для пользовательского интерфейса
2) во всех остальных случаях при сохранении модели этого поля вообще не будет. Но если при регистрации этого поля не было, должна быть ошибка валидации
3) более того, если потом мы решим, что два раза поле вводить неудобно, а лучше сделать одно поле и "глазик" (показать-скрыть пароль), менять придется код именно модели. А с фига ли?
1) это поле нужно в одном частном случае, и вряд ли является логикой модели пользователя - все же это скорее view-логика, ведь это поле нужно исключительно для пользовательского интерфейса
2) во всех остальных случаях при сохранении модели этого поля вообще не будет. Но если при регистрации этого поля не было, должна быть ошибка валидации
3) более того, если потом мы решим, что два раза поле вводить неудобно, а лучше сделать одно поле и "глазик" (показать-скрыть пароль), менять придется код именно модели. А с фига ли?