TIP: Use Markdown or, <pre> for multi line code blocks / <code> for inline code.
These forums are read-only and for archival purposes only!
Please join our new forums at discourse.kohanaframework.org
  • Всем привет! Работаю с фреймворком долгое время и за это время сформировались его недостатки (строго имхо):

    1. Нотация under_score ( мне ближе camelCase )
    2. Принцип autoload (иногда не понятно в каком же модуле переопределили базовый класс фрейма, особенно когда модулей за несколько десятков). Да и не оптимально перебирать директории при поиске.
    3. Нет понимания, что есть модуль, что есть компонент. В модулях может быть и целый проект, классы которого переопределяют классы фрейма, и в тоже время модуль может быть просто набор библиотек.
    4. Router интересен свой простотой, но слаб в функционале, если сравнивать с Yii, или Symfony2
    5. Невнятный принцип обработки Exception, когда верстка html-ошибки выводится где-то в контентной части страницы и ее еще найти надо.
    6. ORM слаб в работе и чаще мешает даже на элементарных вещах и начинаются костыли в виде DB::*. Хотя напротив должен максимально ускорять разработку прототипа проекта.
    7. DB - это отдельная песня, особенно на проектах которые переделывал. Найти где и каких соединений наплодили кодеры утомительное занятие.
    8. Архитектура самого фреймворка и его компонентов изобилует статическими методами, синглтонами. Что негативно сказывается при написании тестов. Особенно если проект готов, большой и его надо обернуть тестами.

    Это наиболее основные, на мой взгляд, косяки, которые разработчики фреймворка не будут исправлять ибо они идут вразрез с тем, что уже есть.

    Поэтому форкнули с коллегой ветку и начали реализацию задуманного. Интересно было бы услышать, какие на ваш взгляд недостатки во фреймворке? Возможно мы что-то упустили.

  • Не нравится много стаитки, а нравится camelCase

    и работа с компонентами? Зачем же переписывать

    такой замечательный инструмент как Kohana!

    Некоторые уже позаботились о таких как вы ;)

    Illuminate Components - уже можно тестировать...

  • +1 посмотрите на laravel4 aka illuminate

  • Зачем же переписывать

    Не совсем переписывать, скорее доработать.

  • Бегло посмотрел illuminate - очень даже хорошо. Спасибо. Надо бы попробовать его в бою. Только в упор не нахожу маны на компоненты.

  • Бгг ....

    1. То, что ближе вам, не недостаток Kohana, а ваше личное предпочтение.
    2. Ну перебор ведь кешируется, а какой класс используется можно посмотреть в логах. Автолоадер можно и отключить.
    3. Хм, напишите чего можно сделать там, а нельзя здесь. Еще не сталкивался ни разу с какими то ограничениями.
    4. Exception переопределяется и ведет себя ровно так, как вы пожелаете.
    5. Штатный ORM может и слаб, но кто мешает использовать например Doctrine ?

    Мне Kohana нравится своей простотой и в нем нет ничего лишнего.

  • тада... кстате, а это правда что версию 3 коханы фактически один человек развивает??? если да - то это единственый минус пока что. всётаки как не крути, а один человек врядли сделает самое лудшее.

  • @Kurk_SS

    А что здесь развивать-то? Исправлять мелкие баги?..

    Тот же Symfony, формально развивается одним девелопером,

    а фактически - огромным сообществом, равно как и Laravel.

    Тем паче, что Kohana - зрелый, устойчивый продукт...

    Тот же Laravel4 - еще пока в глубокой бете. По сути,

    Kohana, является уже отработанным материалом...

    Если любопытно, проверьте ссылку. В подтверждение

    моих предположений: слайд - 14 Framework Evolution

  • @ButscH

    1. Как и отметил, это сугубо имхо. Делаем в первую очередь для себя. Мне кохана самому нравится, в силу своей легковесности.

    2. Повторюсь, при большом количестве файлов(проекты когда не маленькие) искать такие подводные камни проблематично. Перебор сам по себе хоть и кешируется, но не оптимален в эру неймспейсов.

    3. Ограничений нет. Компонет, в моем понимании, набор классов. Модуль - полноценное приложение (и со своей статикой, роутами и т.д.)

    4. Вот и хотелось, чтобы адекватное поведение было из коробки.

    5. Монстр, тяжелее чем сама кохана. Юзал - не понравилось. По легковесности и удобству, мне наиболее понравилась AR от yii.

  • @S.Zares Поковырял вчера Laravel4 , идеи хорошие. Но сейчас это выглядит как надстройка над симфони 2

  • @miron

    И сейчас... и потом... это будет базироваться на независимых

    компонентах, в точ числе - на Symfony2 компонентах

    (не путать с фрейморком Symfony2).

  • @medar Laravel печаль просто а не фреймворк, ничего нового там нет, только имена классам написали такие чтоб хипстерам нравилось ( Eloquent, Blade...)

  • Пока в работе особых недостатков и не замечено. То, что это один из самых легких фреймворков - однозначно. Документация - прелесть, все доходчиво расписано.

    А что с ОРМом не так? Каких функций не хватает? Все что мне необходимо было дописал сам, что перетекает теперь из проекта в проект. Так же и собственные хелперы, обрастают мясом.

    В роутах чего не хватает?

    Мне на самом деле интересны не только недостатки, которые описал ТС но и их обоснования, может тоже надо обратить внимание, или может существует уже их реализация.

  • Так я не говорю что не хватает, просто ничего особо нового там нет, тогда для чего использовать ее если есть та же самая кохана только постабильние. Кстати вот например http://phpixie.com легче и функции фактически калька с кохани но всего лиш несколько класов и где то 100 кб кода

  • @dracony

    Кстати вот например http://phpixie.com легче и функции фактически калька с кохани но всего лиш несколько класов и где то 100 кб кода

    Пожалуйста больше не показывайте никому это убожество.

  • @dracony, это Вы так пиарите свой фреймворк? Попытка переписать интерфесы коханы на свой мотив???

  • Ну чуток =) Просто как раз перед тем как писать пробовал форкнуть ларавел а потом разочаровался. Сорри за оффтоп кстати а то тема то совсем и не о ларавел даже. о Если по теме то недостатков в кохане не вижу, особо из перечисленных, автор фактически написал что не согласен со стилем кода а не в работе системы. Насчет:

    Невнятный принцип обработки Exception, когда верстка html-ошибки выводится где-то в контентной части страницы и ее еще найти надо.

    тут конечно правда, иногда случается такое, но это скорее баг чем недостаток =)

  • Кстате, как по мне - каскадная файловая система - и как следствие перебор каталогов для поиска нужного файла, это не недостаток или плюс, это просто решение задачи маленький фреймворк с гибкой возможностью расширения на своё усмотрение.

    и при правильном использовании, не надо думать где переопределено поведение - это очевидно - в папке апликейшин.

    это по сути тоже как переопределение глобальных вещей в локальном контексте. систем это глобальный функционал системы, + модули, а апликейшины - котоых может быть и несколько, это локально.

    Мирон - а что ты имел ввиду про неоптимальность перебора в эру неймспейсов? просто как я понял - сдесь речь(в кохане) не про разделение, а про перекрытие, что класы наши должны закрывать аналогичные системные или модулей...

  • Единственный очевидный недостаток для меня это отсутствие генераторов кода, моделей и т.п., как в Symfony 2 том-же. Миграции уже есть, всё хорошо, работает быстро, хайлоады на нём делать вполне реально.

  • Если не ошибаюсь, можно генератор и в IDE сделать (PhpStorm вроде как может)

  • Не ошибаешься, но всё-таки нативная поддержка и генераторы это немного разные вещи =) Тот-же cli app у symfony 2 это просто ад, в кохане и не пахло близко ничем таким. ИМХО Kohana очень медленно развивается уже =(( Когда у SensioLabs уже есть и такая штука http://desktop.sensiolabs.org/, Kohana стремительно сдаёт позиции, не удержать за счёт функционала написанного в 3.0 и патчуемого от версии к версии. От перехода на Fuel меня удерживает только откровенно лажовая система роутинга там, и жуткие неймспейсы, везде писать \Class\Name это опять-же ИМХО какое-то говно.

  • у Kohana нет такого активного сообщества, которое бы развивало инфраструктуру фреймворка. Главное сделано - шикарный фундамент (собственно ядро фреймворка + основные модули). Остальное обычно пользователи делают. Но вот как-то сложно с этим

  • @SVat И не убожество кстати, вот те бенчмарки http://phpixie.com/blog/php-framework-benchmark/

  • // Laravel печаль просто а не фреймворк, ничего нового там нет, только имена классам написали такие чтоб хипстерам нравилось

    Как минимум там есть events, полноценный мануал, человечески-понятный синтаксис работы с БД (а не DB::query(Database::SELECT, "...")). Плюс внимание аудитории, что очень ценно. Вон, например, cms уже есть в виде штатного модуля к фреймворку - http://pongocms.com/ . Плюс четвертая версия, которая будет полностью composer-powered и с заточкой на тестируемость любого компонента. Не то чтобы это киллер-фичи, но нельзя сказать, что ничего нового нет.

  • @dracony Никого не интересуют бенчмарки в наше время, сорри, ты выбрал не тот путь. Вон, phalcon в виде сишного расширения всех рвет по бенчмаркам со здоровенным отрывом, а в топе гитхаба по букмаркам и форкам все равно почему-то монструозная symfony2.

  • @medar, я видел, что много народу пишет про DB::query как неудобно, а что в нем не так? Как по мне, то все понятно. Почитал про события в Laravel, так по мне необходимую функциональность прикрутить легко, может чего не знаю или не понял.

    @dracony, по приведенной ссылке бенчмарков у коханы вполне хорошие результаты.

    И тогда понятный вопрос, на что идти дальше? Для меня показателем являются кол-во работы на биржах под конкретную CMS, сегодня это Symfony и YII, но после вводного ознакомления они меня не вдохновили.

  • Ну я нигде не говорил что кохана чем то особо плохая. Завтра еще набенчмаркаю запросов в секунду чтоб поточнее. Насчет CMS то на кохане тоже есть несколько, впрочем мне всегда казалось лучше прикрутить фреймворк к вордпрессу как плагин чем юзать модули цмс. Фалкон конечно прикольно, но вот патчить его на сишке если понадобится то трудно будет. Тогда уж лучше попробовать hip hop php чтоб весь пхп код перевести в си. Правда он тоже не идеален.

  • @medar, я вот не нашел особых плюсов в DB::query у laravel перед kohana. Разве что чуть короче запись. При этом, обязателен правильный порядок параметров, передаваемых в запрос (поправь, если я не так понял документацию). В плюсах у ko3: именованные параметры в запросе (а-ля pdo), отложенное выполнение запросов и пр. Но вообще, у меня давно есть идея, найти более легковесную замену модуля database в ko3 или вообще использовать голый pdo...

    Events я довольно активно использую в своих проектах на ko3.2. Правда, у меня модуль значительно проще, как по функционалу, так и по восприятию. Events в laravel мне не понравился.

    Вчера был 3-й подход к laravel - пока не удачно, не удобной фреймворк, после ko3.2.

  • Ларавел поделие.

  • @aktuba Я имел в виду только простоту записи.

    А events в ларавеле встроен в ядро хуками - http://jasonlewis.me/article/laravel-events , отдельная либа это все-таки другое.

  • @biakaveron Это сообщество распугали сами авторы фреймворка и непонятной политикой "одобрения" комитов.

    @Kurk_SS Как и обозначил, каскадная файловая система это геморрой лютый когда имеется множество модулей, и в каком-то из них вдруг внезапно кодер надумал что-то переопределить. Да и каскадный поиск ныне легко заменяется namespace-ми.

    @Ramallah Начиная от синтаксиса ORM::factory('model'), который мешает в поиске определения модели, до отсутствия валидации по сценариям как yii. Можно писать свои решения, но когда каждый кодер в проекте городит свои решения, модели становятся трудно-поддерживаемыми или неуправляемыми. Во всех проектах на кохана, в которых принимал участие, везде видел страшнейшие костыли. Хотя на том же уii базовые вещи сделаны из коробки, соответственно, их в основном и юзают. Отсюда и код почище, хотя код самого yii - вызывает вопросы.

    Еще момент - это hmvc у коханы. Еще как-то можно понять разделения на 2 типа запросов: внешние - обращение из браузера к контроллеру, внутренние - вызов контроллера из контроллера. Но вот обращение к удаленным ресурсам через CURL, имхо бесполезная вещь. Ведь если код разбросан по удаленным серверам, то сервер делающий запросы будет ожидать ответы остальных, а это дикие задержки. Все эти запросы на клиенте должны делаться аяксом.

  • Это сообщество распугали сами авторы фреймворка и непонятной политикой "одобрения" комитов.

    А можно подробнее? Каким образом разработчики ядра могут повлиять на разработку остальных модулей, которые не относятся к "коробке"? Просто на данный момент в большинстве своем девелоперы каждый сам по себе, и велосипедят кто как может.

    Как и обозначил, каскадная файловая система это геморрой лютый когда имеется множество модулей, и в каком-то из них вдруг внезапно кодер надумал что-то переопределить. Да и каскадный поиск ныне легко заменяется namespace-ми.

    Если "внезапно" кодер меняет что-то важное, то это не проблема фреймворка. Достаточно определенных стандартов кодирования и организации процесса коллективной разработки. В конце концов, модуль не должен вносить изменения в ядро фреймворка (ну или для этого должен быть отдельный "системный" модуль).

    Начиная от синтаксиса ORM::factory('model'), который мешает в поиске определения модели,

    А что мешает использовать new Model_Foo?

    до отсутствия валидации по сценариям как yii.

    В последних версиях правила валидации вынесены в отдельный метод rules(), в нем можно какие угодно проверки/сценарии реализовать.

    Но вот обращение к удаленным ресурсам через CURL, имхо бесполезная вещь. Ведь если код разбросан по удаленным серверам, то сервер делающий запросы будет ожидать ответы остальных, а это дикие задержки. Все эти запросы на клиенте должны делаться аяксом.

    Даже если это и бесполезная вещь (с чем можно поспорить), то по крайней мере не вредная и жить не мешает.

  • Насчет запрсов по курлу, это просто одна из фич HMVC и ничем она не мешает, мне пригодилась разок

  • Просто на данный момент в большинстве своем девелоперы каждый сам по себе, и велосипедят кто как может.

    Да, это болезнь всего современного web-dev сообщества!

    Раньше писали на Perl - худо, бедно, но... неплохо было.

    Затем зашел молодняк и сказал нам: до этого вы все

    делали не так, нужно вот так.., примерно, как на PHP.

    Ну... подождите чуток, мы вам все покажем и расскажем...

    Раз уж так, в ожидании чего-то нового, потихоньку

    перебрались на PHP. А тут! Кто во что горазд...

    Различные направления, стили, кланы со своими уставами...

    И ведь что характерно - каждое сообщество зазывает к

    себе потенциальными возможностями использовать опыт и

    наработки твоих предшественников, но, как правило,

    каждый из них уже сумел (успел) испортить то, что

    еще вчера, возможно мне и подошло бы...

    Особенно это получило свое развитие в период, когда

    толпы кодеров из Java рынули в PHP - это был коренной

    перелом в развале тех немногих основ, благодаря которым,

    многим, именно этот язык программирования нравился

    больше всего. А главное - все это прогрессирует!

    И просвета нет. Мы скоро утонем в этих сугробах

    PHP мусора...

  • @S.Zares, ну вы прям php-летописец :)

    По теме, я вижу плюсы kohana только в том, что из этого фремворка можно вырезать для себя уже готовый, реализованный с умом (не весь конечно), адекватный (в отличии от других фреймворков), многими проверенный базовый функционал. Разделение на модули и каскадная файловая система в конечном проекте нахер не нужны, потому что в итоге всё равно всё жестко связано и обновлять полностью ядро на рабочем проекте вы всё равно не будете, так как в случаи с kohana это чревато последствиями. Убирайте нах классы пустышки из ядра, не переопределяйте где то классы ядра, а прямо их и расширяйте или изменяйте, так как если вы расширяете или изменяете функционал ядра для одного проекта, то этот функционал вполне может понадобится вам и для другого проекта. Нужные модули вынесите так же в ядро. От проекта к проекту расширяйте ядро под себя и клепайте приложения одно лучше другого не думая о kohana. Вот и вся истина, господа. PHP есть PHP.

  • @SVat

    Да нет, я просто очень стар, даже по современным

    свежим меркам, чтобы ничего не замечать вокруг...

    Ведь программировать я начинал еще на Fortran,

    и до сих пор обожаю Haskell ;)

  • Да и каскадный поиск ныне легко заменяется namespace-ми.

    @miron , может я чего-то не понимаю и не изучил, но... Как неймспесы заменят каскадный поиск?! Вот у меня в модуле переопределен класс Controller и везде в приложениях я юзаю именно Controller, а не Kohana_Controller или Application_Controller. И как неймспейсы, без каскадного поиска, помогут приложению понять, что надо использовать файл Controller.php из модуля, а не из системы?

  • @aktuba,

    И как неймспейсы, без каскадного поиска, помогут приложению понять, что надо использовать файл Controller.php из модуля, а не из системы?

    Только так, как это сделано в говно-фреймворке fuel, через class_alias :)

  • я удивляюсь как можно было так плохо запилить неймспейс в пхп.... без import korova.* смысла нет с них

  • @aktuba автолоад определяет по неймспейсу где хранится класс + DI контейнер.

    $loader->registerNamespaces(array(
        'Symfony' => __DIR__.'/../vendor/symfony/src',
        'Monolog' => __DIR__.'/../vendor/monolog/src',
    ));
    
    $container = new Pimple();
    $container['controller'] = new MyController;
    

    Пример не реальный, но все же показывает идею.

    @biakaveron

    А можно подробнее? Каким образом разработчики ядра могут повлиять на разработку остальных модулей, которые не относятся к "коробке"? Просто на данный момент в большинстве своем девелоперы каждый сам по себе, и велосипедят кто как может.

    1. Частая смена ядра разваливает модули. Рано или поздно, кодеров утомляет поддержка своих модулей для разных версий и они забивают на сопровождение.
    2. Фрейм легкий, но лысый. Из коробки не хватает модулей, типа пагинации и т.д. Они вроде бы и есть, но почему в коробку так их и не добавляют. Хотя это явно не навредит, кому нужно - тот заюзает.
    3. Видел ряд патчей, которые ооочень долго рассматривали перед применением или вообще отвергали.

    Если "внезапно" кодер меняет что-то важное, то это не проблема фреймворка. Достаточно определенных стандартов кодирования и организации процесса коллективной разработки. В конце концов, модуль не должен вносить изменения в ядро фреймворка (ну или для этого должен быть отдельный "системный" модуль).

    Согласен лишь частично, что это не проблема. Ибо такая возможность неявного переопределения может сильно усложнить жизнь, если вдруг кто-то учудил. А новички чудят ой как часто . В большинстве случаев приходил работать на проект, который был уже кое-как написан, и потому сталкивался с адскими костылями, которые переделывал. Естественно, многое зависит от квалификации, но неявные вещи лучше заменить более предсказуемым поведением.

    А что мешает использовать new Model_Foo?

    Я использую Model_Foo::factory() :) но, опять же новички юзают синтаксис из манов и потому приходится иной раз перепроверять откуда модель подгрузилась.

    В последних версиях правила валидации вынесены в отдельный метод rules(), в нем можно какие угодно проверки/сценарии реализовать.

    Это плохо, как и писал, там иной раз творится вакханалия по генерации массива с правилами :)

    Даже если это и бесполезная вещь (с чем можно поспорить), то по крайней мере не вредная и жить не мешает.

    Не мешает, согласен. Но в разработке подход мало применим (именно как его позиционируют - для масштабирования кода). Или возможно ошибаюсь, приведите, пожалуйста, пример использования.

    Вот и появилась идея, не делать революций, а форкнуть и допилить.

  • @miron Вам нужен любой фреймворк, кроме Kohana, в них нет проблем!

    Смысл жаловаться, что все не по вашему и все равно использовать? Возьмите например Codeigniter и не нойте, можете Yii поробовать, в них все так, как вам нужно.

    Я пользуюсь kohana уже больше года и ни разу не жаловался ни на архитектуру приложения, ни на кривость сторонних модулей, т.к. изначально знал, что буду использовать.

    Перед установкой стороннего модуля я тщательно изучаю его поведение, т.к. собираюсь им пользоваться и возможно переделывать под свои нужды.

    Вам не нравится ORM или Model, сделайте по своему, ведь вы разработчик. Думаю у каждого приверженца фреймворка есть свои наработки, которые он использует.

    Если взять любой фреймворк и попросить новичка или плохого программиста написать на нем приложение, думаю пусть это будет фреймворк даже с самым предсказуемым поведением, получится говнище.

    Я использую Model_Foo::factory() :) но, опять же новички юзают синтаксис из манов и потому приходится иной раз перепроверять откуда модель подгрузилась.

    ХМ, сколько мест вы знаете, откуда может подгрузиться модель Model::factory('foo') ?

    Model_Foo::factory() в стандартной реализации нет, хотелось бы увидеть код, что он такого особенного делает.

    И какая вероятность того, что Model_Foo::factory() и Model::factory('foo') будут работать по разному?

    Это плохо, как и писал, там иной раз творится вакханалия по генерации массива с правилами :)

    Пример в студию, и как это должно быть по вашему

    Но вот обращение к удаленным ресурсам через CURL, имхо бесполезная вещь. Ведь если код разбросан по удаленным серверам, то сервер делающий запросы будет ожидать ответы остальных, а это дикие задержки. Все эти запросы на клиенте должны делаться аяксом.

    Не совсем понял, через ajax делать запрос на сторонний сайт? и забирать с него данные?

    Вот и появилась идея, не делать революций, а форкнуть и допилить.

    Мне кажется такие идеи появляются у тех, кто только начал программировать и прочитав одну книгу почувствовал себя гуру и взглянув на очередной код, понял что он написан не как по книге и решил все исправить.

    Много раз видел людей, которые не смогли осилить документацию и начинали говорить, что: Фрейм легкий, но лысый. Из коробки не хватает модулей, типа пагинации и т.д. Они вроде бы и есть, но почему в коробку так их и не добавляют.

  • @ButscH Ветку читали вообще?

    Не ною, а есть возможность сделать для себя удобное решение. От коханы появилось много форков, часть из них вполне живые (fuel, laravel). Это как минимум показывает есть что латать. А опыт у меня не только с коханой , и не только с пхп, поэтому есть с чем сравнить. А раз за больше чем за год не нашли в ней откровенных кривых мест, значит и не сравнивали с нынешними фреймворками, хотя бы с тем же yii.

  • @miron читал

    Вы все втираете как круто в laravel и fuell, все там есть, но собираетесь форкнуть kohana и сделать с приятелем очередную поделку.

    Плюс Kohana в том, что он не имеет ничего лишнего, он очень гибок, понятно написаный код и каждый разработчик сам решает как и что должно работать. По сути разработчики предоставляют только базовые инструменты, все остальное ваша фантазия.

    Я использую Model_Foo::factory()

    Надеюсь это не будет главным изменением в вашей поделке?

    А раз за больше чем за год не нашли в ней откровенных кривых мест

    То, что для вас кривые места, для других может быть преимущества. В этом я убедился, читая ваши комментарии.

    Как минимум там есть events Чем отличаются от Observer?

    человечески-понятный синтаксис работы с БД

    Не знаю как вам, но мне хватило 5 минут взглянуть в APIи код, чтобы понять как и что работает

    И все таки хотелось бы услышать ответы на комментарий выше!

  • @ButscH Все мои претензии описаны в 1 посте к кохане, если бы вы его внимательно прочли, обратили бы внимание, что имелось ввиду под "кривыми местами". А именно обилие статический свойств, методов и т.д, что мешает нормальному тестированию. Если это для вас преимущества, то странно.

    Если laravel и fuell подделки, то объясните как им удалось оттянуть уже половину пользователей коханы:) Выше кинули ссылку на laravel 4, обратите внимание. Когда-то кохану называли подделкой, ведь в прошлом это форк CI.

    Все изменения описанные мной делаем с коллегой, в первую очередь для себя. Исходники откроем, кому интересно - посмотрят.

  • Недавно обсуждал идею складирования и совместной разработки/сопровождения основных модулей (то есть ближайших к "коробке"). Те же кодогенераторы, менеджеры таблиц... Добавить туда модули, которые разработчики выкинули из коробки (pagination, OAuth). У многих есть собственные наработки, которые стоит выложить на Гитхаб и совместно тестировать/допиливать.

    Есть желающие поучаствовать? Или будем свои велосипеды осваивать? :)

  • Я за любой кипиш кроме голодовки :)

  • Я всегда за, ато чето расслабился немного! :S

  • @aktuba автолоад определяет по неймспейсу где хранится класс + DI контейнер. Пример не реальный, но все же показывает идею.

    Пример вообще из другой области... Модули практически так юзаются в kohana. Или я не правильно понял пример? Давайте проще - покажите, как обойтись без каскадной структуры (и class_alias) и при этом иметь возможность расширить/подменить класс View, например. Очень хотелось бы подобное увидеть.

    А раз за больше чем за год не нашли в ней откровенных кривых мест, значит и не сравнивали с нынешними фреймворками, хотя бы с тем же yii.

    Я сравнивал. Работал с CakePHP, CI, Kohana, Fuel, Yii и десяток мелких фреймов юзал. Кривые места есть В ЛЮБОМ фреймворке, из тех что я юзал. При этом, самый удобный из всех (для меня, конечно-же), пока является Ko3.2 (плавно перемещаюсь к ko3.3, но вот в нем как-раз много интересных багов )). Yii - мягко говоря, не удобный фрейм. Да, в нем куча всего из коробки, но и лишнего (мешающего мне, например) - куча.

    А именно обилие статический свойств, методов и т.д, что мешает нормальному тестированию. Если это для вас преимущества, то странно.

    Мне стыдно, но с недавних пор для меня это несомненный плюс. Вам важнее тесты? А мне удобство, скорость приложения, легкое развитие и пр. Тесты - сервисный функционал, который должен помогать сопровождению, а не заставлять меня писать код под тест. Хотя, еще год назад я жестко ругал всех, кто юзает статичные методы (за исключением синглетонов). Сейчас-же, у нас на работе свой фреймворк, в котором ТОЛЬКО статичные методы и ни одного объекта. За 3 года предыдущей версии фреймворка + год текущей - проблем с тестами нет, команда из 7 программистов работает и нарадоваться не может.

    Есть желающие поучаствовать? Или будем свои велосипеды осваивать? :)

    Есть. Готов выделить время под подобную идею.

  • Разработку модулей вынес в отдельную тему, дабы не оффтопить слишком: http://forum.kohanaframework.org/discussion/11432/dopolnitelnye-moduli-dlya-kohana

  • Мдя... после прочтения след. впечетление: очередной топ нытья.

    Почему люди забывают простую истину для каждой задачи свой инструмент, для каждого инструмента свой список решаемых им задач?

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

In this Discussion