Грешные мысли о вьюхах

[Mols]

Мда... по вьюхам много у меня грешных мыслей)))
Вот есть скажем ряд объектов.

Публикации
Сообщения
Комментарии

Эти объекты могут быть показаны
1. на главной (скажем последние 10 из каждой группы)
2.
2.1 на отдельной страничке (для Публ и соббщений)
2.2. Комменты - при любой публикации и сообщении
3. В профиле у пользователя (тоже списки)
4. По результатам поиска (например по ключевым словам)

Блин как хочется сделать какой нить $objModel->toHTML()...
Но вроде не кошерно ...

Теперь ещё...
У каждого из этих объектов есть панелька управления... ну типа "редактировать, удалить, добавить коммент, оценить,..."
Для юзабильности было бы не плёхо, чтобы оно было боль мень однотипно... ну скажем всегда в правом верхнем углу объекта.
То есть для всех них неплохо бы в этом $objModel->toHTML() ещё какой нить вызов типа декоратора... (а там же ж куча проверок... можно ли текущему юзеру редактировать, голосовать ну и пошло поехало)
И низя вроде... и вроде так вкусно выглядит...
Остановите меня а?
Низя ж ведь правда?

 

[гемоглобин]

Мда... по вьюхам много у меня грешных мыслей)))
Вот есть скажем ряд объектов.

Публикации
Сообщения
Комментарии

Эти объекты могут быть показаны
1. на главной (скажем последние 10 из каждой группы)
2.
2.1 на отдельной страничке (для Публ и соббщений)
2.2. Комменты - при любой публикации и сообщении
3. В профиле у пользователя (тоже списки)
4. По результатам поиска (например по ключевым словам)

Блин как хочется сделать какой нить $objModel->toHTML()...
Но вроде не кошерно ...

Теперь ещё...
У каждого из этих объектов есть панелька управления... ну типа "редактировать, удалить, добавить коммент, оценить,..."
Для юзабильности было бы не плёхо, чтобы оно было боль мень однотипно... ну скажем всегда в правом верхнем углу объекта.
То есть для всех них неплохо бы в этом $objModel->toHTML() ещё какой нить вызов типа декоратора... (а там же ж куча проверок... можно ли текущему юзеру редактировать, голосовать ну и пошло поехало)
И низя вроде... и вроде так вкусно выглядит...
Остановите меня а?
Низя ж ведь правда?

Ну введи сущность "виджет" и не мучайся

 

[Mols]

Не понял...
что здесь имеется в виду под словом "виджет" ?
Проблема на самом деле в чём...
В том, что модель будет напрямую знать о представлении...
С одной стороны - вроде не правильно.
С другой... при боль-мень правильной организации вроде проблем не должно создать...
От меня и терзают противоречия)))

 

[Adelf]

замени $objModel->toHTML() на какой-нибудь View('..obj_view..', array('obj' => $objModel,..))->render()?

 

[Koc]

виджет==блок (Маджента) == view helper (Зендфреймворк)

 

[Mols]

Adelf
Koc
Да. Этот вариант тоже рассматривается.)))
И похоже так и надо делать.

 

[domino]

Мда... по вьюхам много у меня грешных мыслей)))
Вот есть скажем ряд объектов.

Публикации
Сообщения
Комментарии

Эти объекты могут быть показаны
1. на главной (скажем последние 10 из каждой группы)
2.
2.1 на отдельной страничке (для Публ и соббщений)
2.2. Комменты - при любой публикации и сообщении
3. В профиле у пользователя (тоже списки)
4. По результатам поиска (например по ключевым словам)

Блин как хочется сделать какой нить $objModel->toHTML()...
Но вроде не кошерно ...

Теперь ещё...
У каждого из этих объектов есть панелька управления... ну типа "редактировать, удалить, добавить коммент, оценить,..."
Для юзабильности было бы не плёхо, чтобы оно было боль мень однотипно... ну скажем всегда в правом верхнем углу объекта.
То есть для всех них неплохо бы в этом $objModel->toHTML() ещё какой нить вызов типа декоратора... (а там же ж куча проверок... можно ли текущему юзеру редактировать, голосовать ну и пошло поехало)
И низя вроде... и вроде так вкусно выглядит...
Остановите меня а?
Низя ж ведь правда?

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

 

[Mols]

имхо как-то слишком дохрена для одного объекта.

Ну откуда такой вывод а?
Кто сказал, что всё это в одном объекте?
Просто есть связи между объектами.
И очень иногда хочется, чтобы каждая сущность умела себя рисовать(со всеми связями и элементами управления).
Как например ->toHTML()
Но тут же возникнут сложности использованием разных видов для объекта.
То есть разные вьювы надо будет конфигурить через сами сущности в контроллере, что само по себе совсем не гуд.
Опять же учитывая то, что в представлении объекта есть часть которая тоже может иметь разные представления (панель управления объектом), то такое конфигурирование очень даже может быть геморным и не прозрачным.
Поэтому юзать хелперы всё ж таки правильнее.
Прямо в вьюве(в общем виде страницы) будем видеть какой вьюв используется для сущности.
Ну а чтобы увидеть какое представление используется для контрольной панельки - надо будет просмотреть вьюв используемый для сущности...
А не лезть в модель и контроллер.

 

[Sokil.Dmytro]

а зачем сущностям уметь себя рисовать? сущность должа уметь быть загруженной, измененной и удаленной, и хватит с нее. А отрисовкой пусть занимаются другие. Ведь вам может быть нужно выводить данные не только в HTML, а и в JSON или PDF например. Вам тогда придется менять класс сущности чтобы дописать $posts->toJSON(), вместо того чтобы просто переопределить вывод. Както оно негибко с вхардкожеными методами вывода, ведь получается что вы смешиваете логику отображаения с логикой оюработки данных

 

[Mols]

Sokil.Dmytro
угу. Именно это я имел в виду в первом посте и в предыдущем. Спасибо, что подвели черту )))
Мысли эти ("грешные") - не правильные. И гнать их надо подальше.

 

[AmdY]

Mols
всё правильно. не правильно - это голой попой на ежей садиться, потому что будет бо-бо. У тебя есть объект с методанными, заведи сервис-объект, который эти данные рендерит и будет всё удобно, не надо молиться на MVC, хот это и на основании MVC можно сделать. завести отдельный контроллер.

 

[Sokil.Dmytro]

AmdY
а чем рендерящий сервис-обьект противоречит MVC?

 

[Mols]

AmdY
Ну.... сервис объект по сути не отличается от хелпера.
Штука тут в чём... представления всё равно должны быть отдельно.
И вызов типа View('pattern_name', $object) на мой взгляд всё таки лучше, чем $oService->render() (здесь тоже придётся вызывать 'pattern_name')
Именно тем лучше, что сразу виден 'pattern_name' (хотя это же можно назвать и недостатком, в случае например изменения имени шаблона)
да и лишних классов не придётся плодить.

 

[korchasa]

А в чем проблема? У вас в шаблонизаторе тега include нет?

 

[Mols]

korchasa
Да это всё навеяно переработкой 3.14здец какого говнокода в говнокод чуть получше.
Там вообще нифига толком нет.
Но это уже не по теме.
В общем по теме вердикт вроде уже вынесен.
Ну по крайней мере для себя я определился.