Комментарии 29
Чем же хороша Kohana, если в ней нужно изобретать такой велосипед?
в CodeIgniter тоже такого нет. Там нужно для этого сторонний модуль ставить. Но тем не менее им пользуется большинство. Тем более что это простая доработка.
А на счет того что — почему нравится?!.. Не хочется разводить споров, просто вам нужно попробовать.
Хороша она своей грамотностью кода и гибкостью. Я пересмотрел много фреймверков, и остановился на этом. Один год писал на Symfony — больше не хочу (хотя по началу очень нравилась). Тут сколько людей столько и мнений. Но если попробуете Kohana непожалеете. Осваивание документации — это половина рабочего дня. Документация средней вшивости. Но есть большое преимущество — легко читается код ядра. Я с ней работаю уже 3 месяца, в итоге знаю ее ядро как пять своих пальцев.
Но я незнаю ваших задач — поэтому не факт что вам она тоже подойдет.
А на счет того что — почему нравится?!.. Не хочется разводить споров, просто вам нужно попробовать.
Хороша она своей грамотностью кода и гибкостью. Я пересмотрел много фреймверков, и остановился на этом. Один год писал на Symfony — больше не хочу (хотя по началу очень нравилась). Тут сколько людей столько и мнений. Но если попробуете Kohana непожалеете. Осваивание документации — это половина рабочего дня. Документация средней вшивости. Но есть большое преимущество — легко читается код ядра. Я с ней работаю уже 3 месяца, в итоге знаю ее ядро как пять своих пальцев.
Но я незнаю ваших задач — поэтому не факт что вам она тоже подойдет.
А как по сравнению с CodeIgniter?
Скажу — на много лучше!, опять заплюют фанаты Codeigniter, так как они со мной сделали сдесь valeraorg.habrahabr.ru/blog/47041/#comments. Я воздержусь от радикальных высказываний. Ненравится мне когда меня заплевывают без аргументов. Что самое интересное что меня там просто заминусовали, хотя и не высказали ни единого аргумента против. Это явный показатель фанатизма — а я его не люблю. Я люблю взвешенную позицию. И моя позиция такова — CI требует серъезного дотачивания. Но зачем это делать самому если это уже сделали — Kohana. Kohana — это продукт взвешенной оценки недостатков CI. Мое более подробное видение можно узнать по ссылке выше.
Кстати кому интересно, небольшой анонс следующих статей:
1. Продвинутый автолоад (symfony like). Парсятся рекурсивно папки и читаеться каждый файл на наличие классов и интерфейсов. Потом пути к классам складываются в хеш-таблицу и кешируются. Этот автолоад срабатывает после встроенного автолоада Kohana. Работает очень быстро. Применение находит в узких кругах задач. Но вообще вещь полезная. Установка — положить один файл в хуки и включить их в конфиге… и все…
2. Интеграция Doctrine в Kohana. На любителя.
3. Двух проходное отображение. Присоединение стилевых и js файлов на лету.
Может еще чего нит соображу.
1. Продвинутый автолоад (symfony like). Парсятся рекурсивно папки и читаеться каждый файл на наличие классов и интерфейсов. Потом пути к классам складываются в хеш-таблицу и кешируются. Этот автолоад срабатывает после встроенного автолоада Kohana. Работает очень быстро. Применение находит в узких кругах задач. Но вообще вещь полезная. Установка — положить один файл в хуки и включить их в конфиге… и все…
2. Интеграция Doctrine в Kohana. На любителя.
3. Двух проходное отображение. Присоединение стилевых и js файлов на лету.
Может еще чего нит соображу.
забавно.
>мы не можем себе позволить обращаться к области данных из шаблона
и далее
>в шаблоне через статический метод происходит обращение к одноименному контроллеру
)
дело вкуса конечно.
а что если не рожать контроллер заново? а для таких случаев использовать статические методы соответствующего контроллера.
а то получается что для отрендеривания одного контроллера, рождаются другие, которые при отрисовке, в шаблонах могут вызывать третьи и т.д. Понимаю что привел частный случай, но ведь нет никакого контроля, кто кого откуда вызывает, и вероятны растраты ресурсов а в худшем случае и рекурсивные вызовы.
поэтому я все таки отказался от такой практики. у меня контроллер решает что и где показать, и какие данные подготовить.
>мы не можем себе позволить обращаться к области данных из шаблона
и далее
>в шаблоне через статический метод происходит обращение к одноименному контроллеру
)
дело вкуса конечно.
а что если не рожать контроллер заново? а для таких случаев использовать статические методы соответствующего контроллера.
а то получается что для отрендеривания одного контроллера, рождаются другие, которые при отрисовке, в шаблонах могут вызывать третьи и т.д. Понимаю что привел частный случай, но ведь нет никакого контроля, кто кого откуда вызывает, и вероятны растраты ресурсов а в худшем случае и рекурсивные вызовы.
поэтому я все таки отказался от такой практики. у меня контроллер решает что и где показать, и какие данные подготовить.
видимо вы не разобрались до конца.Никакой рекурсии быть неможет сдесь — вы же видите куда вы вставляете компонент. Так сделано в symfony и это очень удобно. Область данных — это модель, а не контроллер, поэтому непонимаю что вас смущает. А кстати метод контроллера можете сделать статическим, только тогда изменить нужно хелпер.
Перенесите пожалуйста в блог Kohana. Теперь у вас уже хватает кармы :-)
видимо не хватает. В опции — куда публикуем? светиться только — мой персональный блог. Или я не до конца разобрался?
Немного не до конца.
Сперва вам нужно зайти вот сюда habrahabr.ru/blogs/kohanaphp/ и нажать на вилку, так, чтоб она попала в розетку (знаю что звучит по-дурацки) :)
Затем начать редактировать свой пост и там уже появится этот блог.
Спасибо за статью :)
Сперва вам нужно зайти вот сюда habrahabr.ru/blogs/kohanaphp/ и нажать на вилку, так, чтоб она попала в розетку (знаю что звучит по-дурацки) :)
Затем начать редактировать свой пост и там уже появится этот блог.
Спасибо за статью :)
Я тоже реализовал концепцию компонентов в своих приложениях, только вдохновила меня реализация их в Yii.
Вынес компоненты в отдельные классы (мне показалось что реализовывать эти компоненты в контроллерах не лучшее решение).
Каждый компонент наследуется от общего класса Widget_Core.
Вызов компонента в представлении происходит через фабричный метод этого класса, т.е. так:
<?=Widget::factory($component_name, TRUE)->render()?>
Widget_Core позволяет закэшировать весь компонент, для этого всего лишь нужно указать вторым параметром в методе factory TRUE.
В данной классе далеко не все реализовано, что задумано, из-за банальной нехватки времени.
Чтобы не быть голословным, вот архив с классом и простым примером:
ifolder.ru/11276566
Вынес компоненты в отдельные классы (мне показалось что реализовывать эти компоненты в контроллерах не лучшее решение).
Каждый компонент наследуется от общего класса Widget_Core.
Вызов компонента в представлении происходит через фабричный метод этого класса, т.е. так:
<?=Widget::factory($component_name, TRUE)->render()?>
Widget_Core позволяет закэшировать весь компонент, для этого всего лишь нужно указать вторым параметром в методе factory TRUE.
В данной классе далеко не все реализовано, что задумано, из-за банальной нехватки времени.
Чтобы не быть голословным, вот архив с классом и простым примером:
ifolder.ru/11276566
Интересная мысль. Только вот нафига вы назвали абстрактый класс с приставкой _Core — это же неправильно (хоть и работать будет).
Скачал посмотрел. Хорошее ваше решение. Правда мое проще. А так по фенкциональности разницы невижу.
ну разница даже сейчас есть, хотя ещё не реализована вся логика до конца, хотя бы в том, что виджет может «сам себя» кэшировать…
и
Во вторых такое решение было принято из следующих побуждений:
В дальнейшем(как руки дойдут), хочу реализовать функционал «управления выводом компонентов», т.е. в шаблоне указаны, где и какие компоненты выводить, но если нам нужно будет отключить вывод для определенного контроллера или его метода какой либо виджет, то через простой интерфейс, без затрагивания самого виджета или шаблона, будет это легко сделать!
и
Во вторых такое решение было принято из следующих побуждений:
В дальнейшем(как руки дойдут), хочу реализовать функционал «управления выводом компонентов», т.е. в шаблоне указаны, где и какие компоненты выводить, но если нам нужно будет отключить вывод для определенного контроллера или его метода какой либо виджет, то через простой интерфейс, без затрагивания самого виджета или шаблона, будет это легко сделать!
Досмотрелся! А как вы параметры будете передавать в компонент, если понадобится?
Просто мы было вдохновлены разными решениями. Я сделал так как в симфони.
Просто мы было вдохновлены разными решениями. Я сделал так как в симфони.
наверное по свободе скрещу два метода
Для kohana уже давно существует Component library, Dispatch для 2.3 или Component для pre3.0 релизов.
Работает как HMVC, т.е. можно сделать что-то вроде:
$article_list=Dispatch::controller('article')->method('list',array(5,'last');
$article_list=Dispatch::controller('article')->list(5);
Работает как HMVC, т.е. можно сделать что-то вроде:
$article_list=Dispatch::controller('article')->method('list',array(5,'last');
$article_list=Dispatch::controller('article')->list(5);
аргументируй ссылками.
потому что ты пишеш полный бред.
ты привел ссылки с раздела HMVC Kohana learn.kohanaphp.com/2008/03/05/hmvc-in-kohana/
уже нашел.
Но а теперь сравни удобство.
уже нашел.
Но а теперь сравни удобство.
все равно спасибо за информацию, извини за грубость. Надо на досуге глянуть что там.
версия 2 моей библиотеки, но опять же не окончательная
forum.kohanaphp.ru/comments.php?DiscussionID=39
forum.kohanaphp.ru/comments.php?DiscussionID=39
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Реализация компонентов в Kohana