Комментарии 29
Ожидал подобного коммента. В данном случае речь идет о безопасности, снижающего присвоение этой cms себе как автору. Временно закодировал. Но скорее всего или сменю лицензию, или выложу оригинал. В любом случае спасибо за мнение.
Я конечно дико извиняюсь, но автор хоть раз с гитом работал?
Просто уж затеял глупость так сделай нормально ибо из истории можно легко вытащить оригинал (https://github.com/yarron/oxidos/commit/ef9dc4f3e30841ebef167f371efc047126078a08)
А вообще если код выложен на github значит он дожен быть полностью открытым, под одной из лицензий на выбор, это прописано в правилах на github.
Да и пользоваться никто не будет если нужно устанавливать некое расширение для php.
Просто уж затеял глупость так сделай нормально ибо из истории можно легко вытащить оригинал (https://github.com/yarron/oxidos/commit/ef9dc4f3e30841ebef167f371efc047126078a08)
А вообще если код выложен на github значит он дожен быть полностью открытым, под одной из лицензий на выбор, это прописано в правилах на github.
Да и пользоваться никто не будет если нужно устанавливать некое расширение для php.
CMS Opencart. Нравится её структура и удобство использования
Серьезно?? Удобство использования? Мне кажется мы живем в разных мирах. По мне, так опенкарт — один из самых ужасных движков
Хром заблокировал загрузку архива т.к. считает, что он может быть вредоносным, а так хотелось посмотреть CMS именно на Kohana т.к. очень мало хороших проектов на данном фреймворке. Из того что знаю, Kohana используется в Ushahidi.
Сам писал корпоративный сайт на Kohana и считаю, что в настоящее время данный фреймворк незаслуженно забыт. Вот теперь планирую переходить к изучению Yii2.
Сам писал корпоративный сайт на Kohana и считаю, что в настоящее время данный фреймворк незаслуженно забыт. Вот теперь планирую переходить к изучению Yii2.
Фреймворк Kohana не то что бы забыт, он просто перестал развиваться, и по сути умер.
Это частично связано с тем что идеи заложенные в нём морально устарели, а что бы это изменить, нужно переписать его почти полностью.
Хотя в своё время был отличным инструментом.
Это частично связано с тем что идеи заложенные в нём морально устарели, а что бы это изменить, нужно переписать его почти полностью.
Хотя в своё время был отличным инструментом.
Согласен с вами. Тоже начал уже. Посмотреть можете и на demo.
хотелось посмотреть CMS именно на Kohana т.к. очень мало хороших проектов на данном фреймворке
Прошу www.kodicms.ru, есть демо сайт
www.kodicms.ru вот — единственная вменяемая цмс на кохана, а то что выше, нужно как минимум — привести в порядок.
Роли пользователей можно кодировать с помощью битовой маски, ну что же, желаем удачи в развитии проекта. Я не против развития Kohana в любом направлении.
Роли пользователей можно кодировать с помощью битовой маски, ну что же, желаем удачи в развитии проекта. Я не против развития Kohana в любом направлении.
www.kodicms.ru вот — единственная вменяемая цмс на кохана
Спасибо :)
Да, надо наверное форкнуть Kohana и своими силами толкать ее вперед. Последний фреймворк, в котором не умер дух «старой школы». Нет DI, нет composer, нет консольного тула.
Ведь для средне-маленьких проектов это на самом деле не особо и нужно, а весь проект зато — это просто файлы, которые можно просто git pull-ом забрать и все. И документация почти не нужна, весь код можно самому за пару дней разобрать.
Не хватало конечно хороших модулей к ней, увы.
Ведь для средне-маленьких проектов это на самом деле не особо и нужно, а весь проект зато — это просто файлы, которые можно просто git pull-ом забрать и все. И документация почти не нужна, весь код можно самому за пару дней разобрать.
Не хватало конечно хороших модулей к ней, увы.
Я около четырёх лет сидел на Кохане, написал на ней несколько больших и хороших проектов. Недавно решил, что хватит на этом, и пошёл изучать Laravel. Сейчас пишу один проект на нём.
Ощущения от Ларавеля — будто использую новую версию Коханы) Суть особо не поменялась, лишь в роутинге немного непривычно.
Среди плюсов лары лично для меня: по какой-то причине ненавистный вам композер, очень простая и ясная документация, огромное количество качественно написанных сообществом компонентов, удобная консольная утилита, удобный встроенный менеджер миграций, поддержка мягкого удаления объектов из базы… И, в довесок ко всему этому, — приятное и отзывчивое сообщество.
В общем, советую и вам его попробовать) Очень хороший и простой фреймворк, который очень даже хорошо заменяет Кохану и, по сути, является её близким родственником.
Ощущения от Ларавеля — будто использую новую версию Коханы) Суть особо не поменялась, лишь в роутинге немного непривычно.
Среди плюсов лары лично для меня: по какой-то причине ненавистный вам композер, очень простая и ясная документация, огромное количество качественно написанных сообществом компонентов, удобная консольная утилита, удобный встроенный менеджер миграций, поддержка мягкого удаления объектов из базы… И, в довесок ко всему этому, — приятное и отзывчивое сообщество.
В общем, советую и вам его попробовать) Очень хороший и простой фреймворк, который очень даже хорошо заменяет Кохану и, по сути, является её близким родственником.
У меня почти такая же ситуация, но очень смущает один момент в Laravel, вопрос, на который я пока не нашёл ответа. Мне очень нравится роутинг в Кохане, может вы сможете мне помочь, как человек, знающий оба фреймворка? Есть ли в Laravel какой-то более-менее нормальный способ делать роуты наподобие кохановских (или как в Yii), или же приходится прописывать каждый роут руками? Ведь в относительно больших проектах роутов могут быть сотни?
Пример роута из Kohana:
Пример роута из Kohana:
Route::set('route', '(<controller>(/<action>(/<id>)))')
->defaults([
'controller' => 'Users'
'action' => 'index'
]);
Да, как я уже написал, система роутинга тут немного непривычная. Недавно на эту тему писали в группе в Вконтакте.
Там предложили такое решение: gist.github.com/vanchelo/2164db7e0e4ffbb4f317
Но я лично просто постарался привыкнуть к стилю Ларавеля. Возможно, их предложение даже более логично в чём-то, кто знает?
Вот пример файла роутинга в моем текущем проекте: gist.github.com/believer-ufa/408d8e1bb236227e29b1
При этом, я активно использую именованные роуты. Они мне нужны для того, чтобы легко генерировать красивые хлебные крошки с помощью компонента «davejamesmiller/laravel-breadcrumbs». Итого, у меня в любом случае в определённой степени вырос код роутинга и этих хлебных крошек, и всё это оказалось связанным. Но лично мне это сильно не мешает, ведь, по сути, ты только один раз это описываешь, а дальше твоё приложение просто работает, кушать не просит. Я сейчас выбрал такой вариант разработки. Что будет позже — посмотрим)
Там предложили такое решение: gist.github.com/vanchelo/2164db7e0e4ffbb4f317
Но я лично просто постарался привыкнуть к стилю Ларавеля. Возможно, их предложение даже более логично в чём-то, кто знает?
Вот пример файла роутинга в моем текущем проекте: gist.github.com/believer-ufa/408d8e1bb236227e29b1
При этом, я активно использую именованные роуты. Они мне нужны для того, чтобы легко генерировать красивые хлебные крошки с помощью компонента «davejamesmiller/laravel-breadcrumbs». Итого, у меня в любом случае в определённой степени вырос код роутинга и этих хлебных крошек, и всё это оказалось связанным. Но лично мне это сильно не мешает, ведь, по сути, ты только один раз это описываешь, а дальше твоё приложение просто работает, кушать не просит. Я сейчас выбрал такой вариант разработки. Что будет позже — посмотрим)
1) вы всегда можете переопределить маршрутизацию на свою
2) вариант с <controller>/<action> не самый гибкий способ задания маршрутизации. Вариант который предлагает Symfony и в частности использованный в Laravel подразумевает что код ваших контроллеров вообще ничего не знает о маршрутизации. Это позволяет называть контроллеры как угодно, хранить их где угодно, делать контроллеры как сервисы и жить при этом счастливо. Боле того, не возникает проблем с генерацией маршрутов внутри приложения, так как мы там так же отвязываемся от кода. Это дает больше гибкости при разработе и поддержке проекта.
2) вариант с <controller>/<action> не самый гибкий способ задания маршрутизации. Вариант который предлагает Symfony и в частности использованный в Laravel подразумевает что код ваших контроллеров вообще ничего не знает о маршрутизации. Это позволяет называть контроллеры как угодно, хранить их где угодно, делать контроллеры как сервисы и жить при этом счастливо. Боле того, не возникает проблем с генерацией маршрутов внутри приложения, так как мы там так же отвязываемся от кода. Это дает больше гибкости при разработе и поддержке проекта.
>ненавистный вам композер
Это неправда, он мне любимый даже
И DI — бесспорно хорошая штука, и консольные тулы нужны.
И в огромном проекте на симфони 2 я все это использую и жить без этого не могу. Но кесарю кесарево. Я и правда считаю, что для маленьких проектов толку в этом всем немного, и как раз для них Kohana был идеальным инструментом.
Laravel обязательно попробую, но чую, увижу в нем куда более крупный продукт для куда более широких нужд
Это неправда, он мне любимый даже
И DI — бесспорно хорошая штука, и консольные тулы нужны.
И в огромном проекте на симфони 2 я все это использую и жить без этого не могу. Но кесарю кесарево. Я и правда считаю, что для маленьких проектов толку в этом всем немного, и как раз для них Kohana был идеальным инструментом.
Laravel обязательно попробую, но чую, увижу в нем куда более крупный продукт для куда более широких нужд
Хватит мучать труп. Это дух старой школы PHP которому давно уже пора на свалку.
Цвета какие-то кислотные, особенно зеленый в админке, причем неактивные пункты меню практически не видны и кажутся недоступными.
Кнопка на сайте в слайдере «Скачать» и «Демо» ведут на несуществующий сайт oxidus.ru
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Путь от новичка до профи: разработка CMS на фреймворке Kohana 3.3