Нет, ну логично, я не спорю, в кохане тоже есть хэлперы (хотя уже и не в столь значимом варианте, как в предыдущих версиях). Просто до сих пор это не было связано в какую-либо систему для сайтов с изменяемым контентным содержимым и разделением на регионы) А я вот, под свои нужды, написал то, что было удобно) Хотя, судя по отзывам, идея должна жить, так что я буду ее развивать)
Ну, быть может, в кохане какая-то своя реализация MVC) В кохане view представляет собой средство загрузки представлений, читай, файлов html (и не только) кода, внедрения в него переменных (присоединением или привязыванием) и рендер с целью возвращения чистого html из объекта. Утрированно, конечно, но в общем)
А контроллер служит для обработки запроса пользователя. Пришел к нам пользователь со ссылкой example.com/buy/milk, мы ему откроем контроллер buy, в котором запустим функцию action_milk, которая должна уже, используя $this->response->body( <что-то>) вернуть внутри «что-то» хоть представление, хоть чистый текст вроде пресловутого «123») Хотя контроллер представляет из себя обычный класс, и наследование в нем сделано, в частности, для расстановки по папкам.
Предположим, у вас есть контроллер «личный кабинет». В нем вам в любом случае надо опознать пользователя по его сессии (или кукам), загрузить общий шаблон страницы, ну и еще что-то. А внутри подпапочки «личный кабинет» есть контроллеры, скажем «фотография», «настройки» и «государственные тайны», которые, наследуясь от «личного кабинета», смогут, во первых, сразу получить доступ к переменной пользователя, заданной в родительском контроллере, а во вторых, уже будут иметь html-окружение, в которое могут вставить свой $content) Фух…
Ну, дописывать функционал самого VIEW, понятное дело, не стоит, ибо системный класс. Расширить его? Как вариант, конечно, но будет некоторая путаница. Единственным вариантом «прослойки» остается отдельный модуль, наполняющий и возвращающий определенный макет. В дальнейшем я планирую сделать две реализации: развить текущую, «контроллерную», и сделать модуль, а пока собираю полезные советы) В любом случае, спасибо за идеи, наталкиваете на мысли!)
Ну, на счет макета, шаблонизатор не предполагает обязательное использование регионов, по умолчанию в нем важен только $content, так что он может загружать как блочные макеты, так и отдельные.
На счет implode, да, была такая мысль, но, по скольку в процессе написания шаблонизатора идеи возникали не меньше, чем до начала написания, то такая конструкция была сделана с целью предумсмотреть дальнейшую возможную обработку элементов)
На счет пары пейджера, согласен, логичнее было бы сделать вторую переменную необязательной)
А JSON код отдает, вот строчки:
if (! $this->request->is_initial() ) // Если запрос вызывается путем HMVC
elseif ($this->request->is_ajax() ) // Если запрос аяксом
else // Если обычный запрос
Наоборот, читал) Впрочем, человек живет себе спокойно десятки лет, работает на работе, покупает приум в кредит, строит дачу, рожает детей, и он спокоен. А вдруг шепни человеку на ушко, что, мол, всем правит таинственная организация, и он, как и остальные, лишь шестеренка в ней, шуму-то поднимется! Как плохо мы живем, какие плохие масоны (заранее извиняюсь, если здесь таковые присутствуют!), и так далее) Хотя, не скажи человеку об этом, он бы и дальше жил, и умер бы в 84 года в окружении трех детей и пяти внуков, счастливый)
Здесь была выбрана реализация шаблонизатора контроллером, а не модулем, для того, чтобы облегчить наследование контроллеров. Когда мы наследует этот главный контроллер, мы получаем полный набор управляющих конструкций, за которыми не нужно следить. Точно так же, как у контроллера есть функции, скажем, after и before, различные add_style и другие добавляют лишь функционал.
А в случае реализации модулем, приходилось бы создавать инстанс модуля, пичкать его управляющими конструкциями, да и вообще, это было бы подключением лишнего класса, что не очень экономно. Хотя, не спорю, эту вещь можно легко переписать и под модуль, но я пока не встречал ни одного такого проекта)
Согласен с пунктом про «гордиться») Иногда это полезно даже для себя, когда спустя N дней/недель/месяцев напрочь забываешь, как работает та или иная штука, и, залезая в ее модули, видишь не только рабочий, но и красивый код, самооценка как-то поднимается)
Маленькое дополнение, все эти конструкции, в первую очередь, являются не выводящими контент, а накопителями, контент формируется уже после окончания работы экшена)
Ну как бы, MVC предполагает, что мы обращаемся к контроллеру, который загружает модель, работает с ней, и выдает нам конкретный View. Потому эта система шаблонизации загружает нужные представления, как любой другой контроллер, просто она делает это в нужные места)
Ну, во-первых, 3.1 была выбрана потому, что хотелось ее изучить, сравнить с 3.0.
А во вторых, всё-таки, Kohana должна следовать принципам ООП, что реализовано в 3.1, в частности, в нормальной проверки на тип запроса функциями is_ajax(), is_initial() и других против прямого обращения к переменным 3.0. Мне показалось это… Приятнее)
Ну да, это как автоматы Киви на улицах — заходишь платить, скажем, на вебмани, вводишь тысячу рублей одной купюрой, автомат тебе — ура, комиссия 0%, радуйтесь! Платишь, получаешь чек — минус сорок 40 рублей комиссии магазину. Приходит на вебмани — еще минус десять рублей самому вебмани. В общем, жуть
Ну, другой вопрос в том, что если бы они подробную распечатку давали, мол, вот тут две копеечки, это за смс, а там семьдесят три копейки — за транзакцию, тогда еще ладно) Но когда у них одна большая толстая графа «накладные расходы», сиди и думай, кому и сколько на карман они посчитали)
А контроллер служит для обработки запроса пользователя. Пришел к нам пользователь со ссылкой example.com/buy/milk, мы ему откроем контроллер buy, в котором запустим функцию action_milk, которая должна уже, используя $this->response->body( <что-то>) вернуть внутри «что-то» хоть представление, хоть чистый текст вроде пресловутого «123») Хотя контроллер представляет из себя обычный класс, и наследование в нем сделано, в частности, для расстановки по папкам.
Предположим, у вас есть контроллер «личный кабинет». В нем вам в любом случае надо опознать пользователя по его сессии (или кукам), загрузить общий шаблон страницы, ну и еще что-то. А внутри подпапочки «личный кабинет» есть контроллеры, скажем «фотография», «настройки» и «государственные тайны», которые, наследуясь от «личного кабинета», смогут, во первых, сразу получить доступ к переменной пользователя, заданной в родительском контроллере, а во вторых, уже будут иметь html-окружение, в которое могут вставить свой $content) Фух…
На счет implode, да, была такая мысль, но, по скольку в процессе написания шаблонизатора идеи возникали не меньше, чем до начала написания, то такая конструкция была сделана с целью предумсмотреть дальнейшую возможную обработку элементов)
На счет пары пейджера, согласен, логичнее было бы сделать вторую переменную необязательной)
А JSON код отдает, вот строчки:
if (! $this->request->is_initial() ) // Если запрос вызывается путем HMVC
elseif ($this->request->is_ajax() ) // Если запрос аяксом
else // Если обычный запрос
А в случае реализации модулем, приходилось бы создавать инстанс модуля, пичкать его управляющими конструкциями, да и вообще, это было бы подключением лишнего класса, что не очень экономно. Хотя, не спорю, эту вещь можно легко переписать и под модуль, но я пока не встречал ни одного такого проекта)
А во вторых, всё-таки, Kohana должна следовать принципам ООП, что реализовано в 3.1, в частности, в нормальной проверки на тип запроса функциями is_ajax(), is_initial() и других против прямого обращения к переменным 3.0. Мне показалось это… Приятнее)