Comments 52
Молодцы ребята из Kohana, я все ждал что Codeigniter оживет, но там только вялотекущая борьба за 1.7.2, и видимо ничего нового не намечается. Так что буду переходить на Kohana.
Вот теперь кохана становится самостоятельным фремворком, а не «чуть получше кодигнитера».
Действительно много замечательных изменений. Надеюсь, что документация будет тоже на уровне — значительно упростится ознакомление и работа с новой версией.
Если я не ошибаюсь, Shadowhand заикался о начале разработки версии 3.2, по-моему не лучшая стратегия: 3.0 еще не выпущена, а уже задумались о следующих принципиальных изменениях.
Фреймворк отличный, но хочется надеяться, что версия 3.0.х проживет хотя бы год, иначе опять придется бросать проекты без обратной совместимости…
Фреймворк отличный, но хочется надеяться, что версия 3.0.х проживет хотя бы год, иначе опять придется бросать проекты без обратной совместимости…
Теперь Kohana стал больше похож на Zend FrameWork. К примеру в части с разбивкой по файлам (Kohana_Database_Query_Builder) и в роутерах.
КакеПхп начинает отдыхать, на сцене два новых борца Юии и Кохана
ждем, ждем.
Доки главное чтобы не забыли.
Доки главное чтобы не забыли.
Когда я сел за Кохану я долго и громко матерился. Чехарда с _Core, убивающая автокомплит раздражала. Хотел сделать ->orderby('md5(id)', 'asc'), фиг там. Кроме rand() ничего нельзя совать. Пагинатор просто ужасает. Видите ли надо указывать номер сегмента со страницей. Ужас, я так понимаю, что url парсится как строка, а не как пары «переменная => значение'.
Документацию давно пора расширять. Надо выкинуть из мануалов доки про Formation и Forge, если они не работают с современными версиями.
Думал я закинуть нафиг этот фреймворк, но версия 3 дает робкие надежды, что все будет хорошо
Документацию давно пора расширять. Надо выкинуть из мануалов доки про Formation и Forge, если они не работают с современными версиями.
Думал я закинуть нафиг этот фреймворк, но версия 3 дает робкие надежды, что все будет хорошо
Толи описано плохо(в данной статье), толи я уставший, не понял какие преимущества у нового роутинга. Контроллер, экшн и парамтеры теперь могут быть в произвольном порядке? Сохранится ли возможность роутить по старому?
> кроме mysql и pdo). Но не волнуйтесь, все это можно будет скачать дополнительными пакетами.
Месяц назад, читал, что «мы не используем ничего кроме mysql», так что закачаешь нужный драйвер можно будет, если кто-то напишет и выложит.
> кроме mysql и pdo). Но не волнуйтесь, все это можно будет скачать дополнительными пакетами.
Месяц назад, читал, что «мы не используем ничего кроме mysql», так что закачаешь нужный драйвер можно будет, если кто-то напишет и выложит.
Главное, чтобы не в ущерб производительности, все эти нововведения…
Толи описано плохо(в данной статье), толи я уставший, не понял какие преимущества у нового роутинга.Описано плохо :) потому что я сам еще в новом роутинге не сильно разбирался.
Сохранится ли возможность роутить по старому?Единственное правило, заданное по умолчанию и которое я привел в статье как раз и роутит по старому.
что с www.kohanaphp.ru/home?
приятно звучит для украинцев название :) (кохана — любимая)
Route::set('default', '((/(/)))')
->defaults(array(
'controller' => 'welcome',
'action' => 'index',
));
В чём смысл указания дефолтного контроллера и действия, если id всё равно обязательный?
->defaults(array(
'controller' => 'welcome',
'action' => 'index',
));
В чём смысл указания дефолтного контроллера и действия, если id всё равно обязательный?
Route::set('default', '(<controller>(/<action>(/<id>)))') ->defaults(array( 'controller' => 'welcome', 'action' => 'index', ));
Повторюсь еще раз, что не разбирался в роутах, но мне почему-то кажется, что в скобках записывается необязательная часть.
Из этого предположения, можно сделать вывод, что запись "(<controller>(/<action>/<id>))" означала бы, что ничто не обязательно, но можно указать контроллер. А если указан action, то становится обязательным и id (т.к. id не окружен своими собственными скобками необязательности). Но это все домыслы.
Из этого предположения, можно сделать вывод, что запись "(<controller>(/<action>/<id>))" означала бы, что ничто не обязательно, но можно указать контроллер. А если указан action, то становится обязательным и id (т.к. id не окружен своими собственными скобками необязательности). Но это все домыслы.
Вот чего не хватает этому фреймворку, так это документации. К сожалению.
да уже сегодня можно с уверенностью сказать, что почти все фреймворки похожи друг на друга чуть менее чем полностью. нет правда :-)
Ну учитывая, то что задача php фреймворков одна, и практически везде используется MVC, было бы странным если бы они сильно отличались.
А вобще не согласен, фреймворки имеют значительные различия, чтобы бросаться фразами «чуть менее чем полностью», если я не прав приведите пример таких нереальных похожестей.
А вобще не согласен, фреймворки имеют значительные различия, чтобы бросаться фразами «чуть менее чем полностью», если я не прав приведите пример таких нереальных похожестей.
ну вот недавно у меня был первый опыт работы с kohana 2.x
всю дорогу не покидало чувство дежа-вю.
всю дорогу не покидало чувство дежа-вю.
Буквально две недели начал использовать ko3 с doctrine. Пока только самые лучшие впечатления от фреймворка.
Ой, я когда с ним разбирался, строчки для генерации Core классов в ядре Kohana
Просто убила… До этого долго удивлялся почему автодополнение не работает… Слава богу что это поправят…
То, что автоконструктор SQL доработали — тоже весьма радует!
Очень жду релиза!
// Transparent class extensions are handled using eval. This is
// a disgusting hack, but it gets the job done.
eval($extension);
Просто убила… До этого долго удивлялся почему автодополнение не работает… Слава богу что это поправят…
То, что автоконструктор SQL доработали — тоже весьма радует!
Очень жду релиза!
Такие конструкторы запросов, иногда заставляют меня задуматься, а не проще ли пользоваться SQL диалектом при условии, что вероятность смены «драйвера» стремится к нулю.
конструкторы запросов позволяет собирать запросы, передавая объект конструктора в различные билдеры-критерии, каждый из которых добавляет к запросу что-то своё.
Возможно моё мнение сформировалось, из-за излишнего сложного класса, для построения строки. И из-за того, что за редким исключением билдеры у меня не в виде цепочки.
В кохана 2, билдер никогда не нравился, особенно из-за своих ограничений.
В кохана 2, билдер никогда не нравился, особенно из-за своих ограничений.
а они и не должны быть в виде цепочки (в нормальных реализациях билдеров)
$criteria = new criteria('table');
advanced_add_pager_function($criteria);
$select = new select($criteria);
$criteria = new criteria('table');
advanced_add_pager_function($criteria);
$select = new select($criteria);
Документацию бы ему ещё и плотное сообщество…
Эээх, о главном забыли написать — HMVC безо всяких лишних усилий! В любом месте приложения можно написать что-то вроде $result = Request::factory('some/url')->execute()->$response; — и получим результат работы скрипта как если бы вызывали его вручную.
При этом первоначальный объект Request (который инициировал работу приложения) доступен через Request::instance();
При этом первоначальный объект Request (который инициировал работу приложения) доступен через Request::instance();
— Первое, что бы хотелось отметить, совместимости с версией 2.3 не будет
Дальше читать не стал. Вот поэтому я и пользуюсь CodeIgniter'ом, а не его многочисленными клонами.
Дальше читать не стал. Вот поэтому я и пользуюсь CodeIgniter'ом, а не его многочисленными клонами.
Sign up to leave a comment.
Что нам готовит Kohana 3