Pull to refresh

Comments 43

Можно подробнее, почему пришлось отказаться от PSR-0? А вообще сейчас PSR-4 используется, он должен подойти. И какая версия Кохана используется?
Версию увидел, 3.3.2. И всё же, почему не прикрутить PSR-4 автозагрузчик рядом с кохановским?
Почему бы не использовать composer?
Проблема в том, что в версии Kohana 3.3 появились зачатки PSR-0, а именно
All class file names and directory names must match the case of the class as per PSR-0., а в связи с тем, что уже был пройден длинный путь разработки на более старых версиях (начальная версия была 3.1 насколько я помню), то привести все названия файлов и классов было уже трудоемкой задачей, которая требовала бы тестирования со стороны пользователей, но аудитория пока что очень маленькая и соответственно самому выловить все баги будет очень тяжело, хотя начало было положено github.com/butschster/kodicms/tree/PSR-0_support благодаря помощи канадского программиста.
Так можно же добавить в стек несколько autoloader-ов, в т.ч. и кохановский lowercase, а за ним PSR4-compatible
А с чем связан вот этот грустный коммит?
remove PHPUnit test files


И да, было бы неплохо для разработчиков и контрибьютеров организовать Vagran-box/docker контейнер с настроенным окружением, что бы потыкать так сказать.
А с чем связан вот этот грустный коммит?
remove PHPUnit test files

Они были убраны из ветки master и dev и оставлены в ветке unittest, которую я создал специально для тестов
Зачем? Какой в этом сакральный смысл? Исключить из дистрибьютива тесты?
Смысл как раз в том, чтобы писать тесты для текущей ветки.
unittest мерджится с dev веткой постоянно, хотя если есть предложения по организации работы с тестами, готов выслушать, для меня показалось логичным включить их в отделльную ветку и в ней проводить написание тестов и т.д.
Не поймите меня не правильно, но по моему это дополнительные издержки, от которых легко можно отказаться. Или у вас были причины на такой шаг? Расскажите пожалуйста — будет интересно.
Мы храним все тесты в корне проекта — папка «test» содержит все тесты. Это в принципе удобно, хотя порой возникает желание положить все тесты определенного модуля в сам модуль. Руки пока не дошли до этого.
CMS понравилась, автор проделал нереальную работу.
RedactorJS (бесплатная версия) в качестве текстового редактора

А это какая версия и где ее можно скачать? Вроде как платно, если с открытым кодом то еще и самая дорогая лицензия или вы купили лицензию?

Раньше был бесплатен. Сейчас за деньги.

Расскажу про наш опыт — мы к сожалению ушли от него на CKEditor, потому что постоянно всплывали проблемы (для юзеров) на продакшине и нашим пользователям это не нравилось. Не знаю как сейчас там дела обстоят, но когда версия была бесплатная — мы сами фиксили баги и даже им оптравляли. Давно это было…
Поддерживаю вас, тоже имел практику внедрения Redactor устаревших версий(бесплатные) однако отказался от него в пользу Ckeditor — намного более удобно расширяемый редактор + наличие неимоверно большого каталога плагинов.
Особенно радует то, что CKEditor достаточно часто обновляется. Иногда в месяц по два раза обновления разворачиваем на продакшине.
В CMS — RedactorJS интегрирован в качестве плагина, также для системы был разработан плагин CKEditor, плюс системы в том, что редакторы не встроены в систему, за исключением редактора ACE.
Это похвально! Вы вообще проделали отличную работу — так держать!
А это какая версия и где ее можно скачать? Вроде как платно, если с открытым кодом то еще и самая дорогая лицензия или вы купили лицензию?

RedactorJS до определенного момента был бесплатным, и лицензирование началось с 9-й версии, если я не ошибаюсь.

https://github.com/html5cat/redactor-js вот, он конечно не такой крутой, как платные версии, мне пришлось его дорабатывать.
Я смотрю нереально всё продвинулось, по сравнению с используемой мной KodiCMS 2.0.0. Надо будет найти время и постараться мигрировать на новую версию)
Труд колосальный, достойно уважения!
Жаль, что разработчики в свое время забили на Кохану, фреймворк умер, и утянет за собой Ваш продукт. Может есть смысл Вам форкнуть Кохану и развивать форк в тандеме с cms?
У человека с трудом хватает времени на развитие CMS, а Вы ему предлагаете еще и фреймворк тащить на себе.

Другое дело, что надо посмотреть на уже существующие форки (насколько я помню, еще несколько CMS привели к таким ответвлениям) и возможно присоединиться к ним. Другой вариант — познакомиться с текущей командой разработчиков Kohana. Да, фреймворк еще не совсем умер, по крайней мере были шевеления в github.com/kohana/kohana/tree/3.4/develop.
Как человеку, работающему, в основном, с Kohana, позволю себе сказать, что слухи о смерти Kohana сильно преувеличены
Возможно вы еще проходите фазу отрицания.

Если брать реальную картину. Последний коммит в версию 3.4.x-dev был сделан месяц назад. Вообще динамика коммитов за последние пол года крайне печальна… Я думаю что вам стоит тихонько так тайком подумывать о том что бы сменить фреймворк для будущих проектов.
Вы знаете, смотрел на Yii2 и Laravel5 в сравнении с Коханой. Да, они чуть-чуть современнее и некоторые моменты мне в них нравятся больше, но это не киллер фичи. Помоему должно пройти лет 5, чтобы Kohana 3.3 превратилась в мамонта как Codeigniter
Ну то что Kohana лучше CI или CakePHP я и не спорю (хотя найдутся люди которые не согласятся). Но вы смотрели скажем Symfony2? Их httpkernel и httpfoundation, систему маршрутизации и т.д. В сторону Laravel или Zend2 — тамошние контейнеры зависимостей скажем выглядит симпатичнее чем тот что в Symfony2 (мне уж больно нравится автоконфигурирование на основе тайпхинтинга и реализаций интерфейсов).

Словом… понимаю что Kohana еще не сильно пахнет, переводить старые проекты с нее на что-то получше не призываю. Но вот делать новые проекты на ней считаю странным.
Смотрел и пишу еще раз, что не считаю это киллер фичами :)

Но вот делать новые проекты на ней считаю странным.

Новые проекты возможно нужно бы было на Yii2 или Laravel писать, но жизнь иногда несправедлива :)
Спорить нет смысла, т.к. действительно, динамика развития Kohana очень слабая. Я к чему клоню, что еще лет так на 3-5 его (ее?) точно хватит. А вечного ничего нет.
maxsite живет — хотя кодигнайт хоронят каждый год начиная с появления))
последний коммит 8 месяцев назад, 45 старгейзеров… Ну да, живее всех живых. И пользуются ей наверное прям так активно активно… и внутри у нее тоже все в лучшем духе проектов на CI.
Очень здорово! Kohana — мой первый фреймворк, очень жаль что он кончился. Заинтересовало вот что
Все типы кеша поддерживают теги кеширования.

Насколько я помню в 3 версии ни один тип кеша не поддерживал теги, вы сами допиливали? Особенно интересует memcache.
Ну собственно в Kohana есть интерфейс Cache_Tagging и из коробки есть поддержка тегов — для MemcacheTag, sqlite, я добавил только поддержу тегов для File (хотя я думаю вообще исключить этот тип кеширования), для APC и MongoDB
На первый взгляд CMS весьма достойная, особенно учитывая что вы писали ее в одиночку. Этот же факт сильно останавливает от ее использования, ведь в какой-то момент у вас могут смениться приоритеты. Вы думали над способами монетизации проекта? Например, по моим ощущением функционально ваша CMS ничем особо не уступает американскому ExpressionEngine от EllisLab, которая кстати написана на предке Коханы CodeIgniter'е. Так вот у них есть бесплатная версия и платная за $300 лецензия. В рашке за эти деньги вероятно удушатся, но если вам удасться вывести свои разработку на глобальный уровень, но можно вполне себе зарабатывать.
Этот же факт сильно останавливает от ее использования, ведь в какой-то момент у вас могут смениться приоритеты.

Есть несколько причин разработки CMS, одна из них это заработок денег, т.е. я выполняю заказы по разработке сайтом и для этого использую свою CMS и трачу на разработку одного сайта менее 3-х дней, вторая причина, мне нравится программировать.
Ну и надеюсь в будущем найдутся люди, которые присоединятся к разработке системы, что снизит вероятность того, что система будет заброшена.
Почему бы не сделать сортирование страниц сразу, без необходимости переключения в режим сортирования? Добавить слева к каждому пункту иконку для сортирования, мне кажеться так будет удобней
Во первых так исторически сложилось, ведь этот модуль делался по аналогии с FrogCMS и FlexoCMS, во вторых ветки в дереве страниц можно сворачивать (а в свернутом виде они не загружаются из бд), поэтому в любом случае для сортировки придется производить дополнительные манипуляции, ну и так меньше вероятности, что это не сделает кто-то случайно.
Автор молодец! Спасибо за труд и успехов в разработке!
С коханой два месяца, влюбился почти сразу.
Посмотрел демку, выглядит очень вкусно.
Желаю побольше чистого и производительного кода!
А я вот на Кохане пару крупных проектов запустил, а потом она умерла.
И я перешел на Zend2 (до этого посмотрев другие современные решения).

Я понимаю, что работы проделано много уже и выкидывать или переписывать свой код жалко, но какой смысл изучать или писать что-то на уже мертвом (отставшем) фреймворке?
Sign up to leave a comment.