Comments 15
Спасибо. Пожалуйста добавте модуль в репозиторий модулей на googlecode.
И переносите в kohana, кармы уже должно хватить.
И переносите в kohana, кармы уже должно хватить.
Чесно говоря не ожидал, что будет такая скромная реакция :)
Критикуйте, спрашивайте, советуйте пожалуйста, мне будет приятно :)
Критикуйте, спрашивайте, советуйте пожалуйста, мне будет приятно :)
Забавно — Кохана — в переводе с украинского — Любимая ;)
Но когда нам нужно вывести макет страницы со сложным расположением элементов, которые могут меняться от раздела к разделу… Что делать? Собирать все из мелких вьюшек в контроллере? Не удобно, особенно если контроллеров много — не дай бог, например, поменяется количество столбцов в разметке, придется в каждом контроллере перераспределять блоки с контентом по столбцам.
Немного не ясно какое отношение имеет разметка и контент к контроллеру. Если я правильно понимаю то согласно MVC архитектуре контроллер отвечает за обработку данных и действий. А разметка и вывод данных пользователю это строго задача представления (View). А может я просто вас не понял. Например в Cakephp можно формировать сложные представления с множеством елементов используя (тавтология) elements, куда можно вынести часто используемые блоки.
Немного не ясно какое отношение имеет разметка и контент к контроллеру. Если я правильно понимаю то согласно MVC архитектуре контроллер отвечает за обработку данных и действий. А разметка и вывод данных пользователю это строго задача представления (View). А может я просто вас не понял. Например в Cakephp можно формировать сложные представления с множеством елементов используя (тавтология) elements, куда можно вынести часто используемые блоки.
За представление отвевает представление, все верно. Допустим у вас макет страницы, у которого предусмотрено содержимое, зависящее от раздела. Как на хабре справа «Популярные блоги» «Прямой эфир» или реклама. Как можно было бы сделать разные блоки в разных разделах? Либо делать для каждого раздела отдельное представление, либо в самом представлении описывать что нам нужно отображать справа. Первый вариант ужасен, второй бы обязал нас в каждом контроллере прямо задавать, что мы хотим видеть справа. Это и код захломляет и неудобно, т.к. это не относится непосредственно к обяъанности контроллера.
С наследованием задачу можно решить более элегантно. Есть базовый лейаут страницы, в котором только вызывается функция формирования правых блоков, и есть её потомки, в которых уже прописаны определнные блоки, которые кстати могут строиться как моделями, так и контроллером через доступный $this->controller. А контроллер только выбирает подходящего под страницу потомк, в котором уже есть информация что нужно показать пользователю справа.
С наследованием задачу можно решить более элегантно. Есть базовый лейаут страницы, в котором только вызывается функция формирования правых блоков, и есть её потомки, в которых уже прописаны определнные блоки, которые кстати могут строиться как моделями, так и контроллером через доступный $this->controller. А контроллер только выбирает подходящего под страницу потомк, в котором уже есть информация что нужно показать пользователю справа.
плохо! смешали верстку с пхп?!
я использую сейчас CI. так вот я пошел по простому способу — сделал возможность из шаблона вызывать плагины\модели-функции… (только есть нюанс с получением переменных в функции, которая должна вызваться)
т.е. в шаблоне (view) вызов выглядит так:
[thumb &pic='{!pic}' &width='60' &height='40']
!pic — Не опечатка! я улучшил парсер, чтобы подставлять значения в вызовы, и что бы не срабатывал вызов из полей документа (обычные {field_name} родного парсера CI).
плюс у меня модель выводит данные в $this->layout->render(string), где данные (view отрендеренный) вставляется в общий шаблон страницы ({page_content}).
я использую сейчас CI. так вот я пошел по простому способу — сделал возможность из шаблона вызывать плагины\модели-функции… (только есть нюанс с получением переменных в функции, которая должна вызваться)
т.е. в шаблоне (view) вызов выглядит так:
[thumb &pic='{!pic}' &width='60' &height='40']
!pic — Не опечатка! я улучшил парсер, чтобы подставлять значения в вызовы, и что бы не срабатывал вызов из полей документа (обычные {field_name} родного парсера CI).
плюс у меня модель выводит данные в $this->layout->render(string), где данные (view отрендеренный) вставляется в общий шаблон страницы ({page_content}).
Я знал что такой комментарий будет :)
> плохо! смешали верстку с пхп?!
Да, смешал верстку с php. При этом не смешал логику с версткой. Даже не знаю откуда взялось убеждение, что нельзя мешать верстку с пхп. Видимо многие отождествляют логику и php.
Вы привели пример, где смешиваете верстку с каким-то другим языком, которого я даже не знаю. При этом считаете, что это хорошо.
> плохо! смешали верстку с пхп?!
Да, смешал верстку с php. При этом не смешал логику с версткой. Даже не знаю откуда взялось убеждение, что нельзя мешать верстку с пхп. Видимо многие отождествляют логику и php.
Вы привели пример, где смешиваете верстку с каким-то другим языком, которого я даже не знаю. При этом считаете, что это хорошо.
>Даже не знаю откуда взялось убеждение, что нельзя мешать верстку с пхп. Видимо многие отождествляют логику и php.
лично мне проще править шаблон, нежели перетряхивать php-файл контроллера\модели…
>Вы привели пример, где смешиваете верстку с каким-то другим языком, которого я даже не знаю
согласен, но {field} парсера ведь яснее и проще при верстке? а ведь это не пхп :-)
я «изобрел» вызов только потому, что:
— мне это понятно (ModX наследие)
— делать визуальный конструктор как в Битриксе мне не охота :-)
лично мне проще править шаблон, нежели перетряхивать php-файл контроллера\модели…
>Вы привели пример, где смешиваете верстку с каким-то другим языком, которого я даже не знаю
согласен, но {field} парсера ведь яснее и проще при верстке? а ведь это не пхп :-)
я «изобрел» вызов только потому, что:
— мне это понятно (ModX наследие)
— делать визуальный конструктор как в Битриксе мне не охота :-)
> нежели перетряхивать php-файл контроллера\модели…
В том то и дело, что это php-файл представления, а не контроллера или модели :)
> но {field} парсера ведь яснее и проще при верстке?
согласен. А еще можно писать {$field}, что не намного сложнее. Именно так я обычно и делаю. Вопрос оформления вызовов методов и вставки переменных в код немного отделен от вопроса, который я решал. Вы можете сделать другой модуль на основе моего, который бы еще раз делал то, что и так делает php. При желании можно даже классы эмулировать. Или могли бы сделать этот модуль не на основе моего, но в любом случае вам пришлось бы его делать, потому что в кохане не предоставляется встроенного шаблонизатора, а предлагается использовать plain-php, о чем я и сказал в статье. И мне не понятно почему вы этот шаблонизатор спрашиваете с меня. Но еще раз повторюсь, мне лично удобнее работать с php в качестве шаблонизатора.
В том то и дело, что это php-файл представления, а не контроллера или модели :)
> но {field} парсера ведь яснее и проще при верстке?
согласен. А еще можно писать {$field}, что не намного сложнее. Именно так я обычно и делаю. Вопрос оформления вызовов методов и вставки переменных в код немного отделен от вопроса, который я решал. Вы можете сделать другой модуль на основе моего, который бы еще раз делал то, что и так делает php. При желании можно даже классы эмулировать. Или могли бы сделать этот модуль не на основе моего, но в любом случае вам пришлось бы его делать, потому что в кохане не предоставляется встроенного шаблонизатора, а предлагается использовать plain-php, о чем я и сказал в статье. И мне не понятно почему вы этот шаблонизатор спрашиваете с меня. Но еще раз повторюсь, мне лично удобнее работать с php в качестве шаблонизатора.
> плохо! смешали верстку с пхп?!
Пока рулят php — шаблонизаторы, всегда будут попытки смешать php html и какой-нибудь местечковый язык шаблонов. При этом не прекратятся дискуссии о том можно ли вызвать model из view.
Пока рулят php — шаблонизаторы, всегда будут попытки смешать php html и какой-нибудь местечковый язык шаблонов. При этом не прекратятся дискуссии о том можно ли вызвать model из view.
Как приятно что этот фрэймверк набирает популярность. Я просто его фан.
все кто еще на несмотрел — обратите внимание не пожалеете.
все кто еще на несмотрел — обратите внимание не пожалеете.
Честно говоря, не увидел никаких плюсов… И вообще не понял смысла :)
Мы ведь присваиваем переменной шаблона какое-то значение (массив или вообще другой шаблон, не суть) — при этом в коде самого шаблона можем поставить вывод этой переменной где угодно и сколько угодно раз.
А для того, чтобы выводить разное содержимое, можно создать хэлпер или библиотеку…
Мы ведь присваиваем переменной шаблона какое-то значение (массив или вообще другой шаблон, не суть) — при этом в коде самого шаблона можем поставить вывод этой переменной где угодно и сколько угодно раз.
А для того, чтобы выводить разное содержимое, можно создать хэлпер или библиотеку…
Sign up to leave a comment.
Модуль для иерархических представлений (View) для Коханы