Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 132
> В CI модель непосредственно связана с базой данных. Других моделей просто нет.
Эм… Насколько мне известно, если при загрузке модели не задать третьему, необязательному, параметеру значение true ($this->load->model('Model', 'model', false)), то модель не будет иметь доступ к базе данных? по крайней мере так вычитал в документации…
Эм… Насколько мне известно, если при загрузке модели не задать третьему, необязательному, параметеру значение true ($this->load->model('Model', 'model', false)), то модель не будет иметь доступ к базе данных? по крайней мере так вычитал в документации…
Как по мне, дак CodeIgniter давненько умер, ничего нового, а их ShopingCart просто окончательно сформировал мою точку зрению по этому поводу. Безусловно, по функционалу и красоте, Yii уделывает CodeIgniter. Но сравнивать живые фреймворки с покойничками, не есть хорошо (:
С удовольствием бы почитал сравнение Yii c Zend Framework.
Спасибо.
С удовольствием бы почитал сравнение Yii c Zend Framework.
Спасибо.
Да, ShoppingCart — это, конечно, был номер…
По поводу «умер» — я бы так не сказал. Кое что всё-таки делается. Совместимость с PHP5.3 вот сделают в следующем релизе, кое-каки ошибки поправят. К тому же на CI сделаны такие занятные штуки, как Cogear, Maxsite CMS и многие другие.
Про ZF… я его как фреймворк последний раз использовал очень давно. С того времени многое изменилось.
По поводу «умер» — я бы так не сказал. Кое что всё-таки делается. Совместимость с PHP5.3 вот сделают в следующем релизе, кое-каки ошибки поправят. К тому же на CI сделаны такие занятные штуки, как Cogear, Maxsite CMS и многие другие.
Про ZF… я его как фреймворк последний раз использовал очень давно. С того времени многое изменилось.
Ой, хорошо что предупредили по-поводу php 5.3, а то на днях хотел попросить обновить версию похапэ, вот порадовался бы (:
Это понятно, что проекты уже написаны и их надо поддерживать, но новые проекты начинать на CI уже становится опасно (:
В общем как-то я скептически настроен к CodeIgniter, плавно переключаюсь на ZF.
Это понятно, что проекты уже написаны и их надо поддерживать, но новые проекты начинать на CI уже становится опасно (:
В общем как-то я скептически настроен к CodeIgniter, плавно переключаюсь на ZF.
Ага, вот только EE2 что-то постоянно откладывается…
Зв ыфзодом EE2 стал следить больше года назад, и тогда они обещали к осени все сделать… полагаю что еще не один год все так и будет…
Согласен с предыдущими высказываниями для меня CI мертв!
нет чего-либо чего нельзя было бы реализовать на Yii.
более того реализзовать красиво :-) так что б душа развернулась и не сворачивалась :))
Конечно у Yii крайне слаба документация, очень мало примеров, людям трудно начинать на нем, однако очень много мест которые интуитывны и не требуют примеры… помню к примеру как я читал про хелпер создающий тэг селект, прочитав API references я понял сразу все, причем после понимания, наступило ощущение что именно этого я давно так хотел, и если б я сам сделал то сделал бы именно так :-)
Конечно каждый инструмент подходит для своих нужд, но Yii странно обладает таким качеством, что его, как по мне, можно использовать абсолютно в любом проекте. Это странное качество отмечено автором статьи как расширяемость, действительно огромный плюс Yii.
Я для себя не полностью открыл Yii но то что уже открыл мне определенно нравится :-) лишь бы ничего не испортили, как бывает иногда :-)
Согласен с предыдущими высказываниями для меня CI мертв!
нет чего-либо чего нельзя было бы реализовать на Yii.
более того реализзовать красиво :-) так что б душа развернулась и не сворачивалась :))
Конечно у Yii крайне слаба документация, очень мало примеров, людям трудно начинать на нем, однако очень много мест которые интуитывны и не требуют примеры… помню к примеру как я читал про хелпер создающий тэг селект, прочитав API references я понял сразу все, причем после понимания, наступило ощущение что именно этого я давно так хотел, и если б я сам сделал то сделал бы именно так :-)
Конечно каждый инструмент подходит для своих нужд, но Yii странно обладает таким качеством, что его, как по мне, можно использовать абсолютно в любом проекте. Это странное качество отмечено автором статьи как расширяемость, действительно огромный плюс Yii.
Я для себя не полностью открыл Yii но то что уже открыл мне определенно нравится :-) лишь бы ничего не испортили, как бывает иногда :-)
Документация
Отличная и актуальная(постоянно приводится в соответствие с релизами), есть перевод на русский и другие языки(кончено, кое чего нет, зато есть русскоязычные ресурсы посещенные фреймворку). Докоментацию можно загружать в различных форматах(html, chm, некоторую в pdf). По ZF написанно несколько книг и довольно неплохих туториалов.
Совместимость
ZF написан на PHP5.2 (с PHP5.3 тоже работает) и не поддерживает PHP4.
Скорость
Очень часто можно говорят что скорость в ZF — узкое место, однако вы вряд ли это заметите, да и вообще вероятность того что вы упретесь в быстродействие фреймворка, крайне низка(точнее в большинстве задач будет неважна), и тогда в этом случае вам может быть вообще не стоит использовать PHP. При использовании кэша и корректной настройки фреймворка(в документации есть небольшой раздел посещенный производительности), вряд ли будет ощютима разница м/у ZF и другими фреймворками.
Структура директорий
ZF — не накладывает никаких ограничений на структуру директорий. Да и вообще не диктует никаких жестких ограничений на разработчика, любые компоненты фреймворка можно использовать независимо.
Автозагрузка
Все необходимые классы грузятся автоматически, автозагрузка сделана на основе spl_autoload, вы можете настраивать стандартный автозагрузчик, или написать совой(вряд ли пригодится).
Роутер
Маршруты можно отключать, есть несколько стандартных маршрутизаторов(точнее шаблонов правил для маршрутизации), можно довольно удобно добавлять свои.
Контроллер
Префиксы — Controller и Action(можно изменить), есть поддержка модульности(объединения контроллеров в модули).
Отображение
Поддерживает layout'ы, view-helper'ы, встроенный view мне нравится, но можно подключать шаблонизатор.
Модель
Нет никаких ограничений на построение модели, есть свой класс для работы с БД, можно довольно удобно подключать ORM(Doctine, Propel).
Валидация форм
Огромные возможности для генерации и валидации форм или других данных.
Расширяемость
Уже писал об этом.
Хуки
Если под ядром иметь ввиду MVC, то можно создавать плагины для Front Controller'a, Action, классов для работы с БД, приложения.
Чего нет
Нет жестких правил для создания приложений, по сути объединять все компоненты фреймворка приходиться самому, хотя с приходом новых версий фреймворка(компонента Zend_Application) ситуация меняется.
Отличная и актуальная(постоянно приводится в соответствие с релизами), есть перевод на русский и другие языки(кончено, кое чего нет, зато есть русскоязычные ресурсы посещенные фреймворку). Докоментацию можно загружать в различных форматах(html, chm, некоторую в pdf). По ZF написанно несколько книг и довольно неплохих туториалов.
Совместимость
ZF написан на PHP5.2 (с PHP5.3 тоже работает) и не поддерживает PHP4.
Скорость
Очень часто можно говорят что скорость в ZF — узкое место, однако вы вряд ли это заметите, да и вообще вероятность того что вы упретесь в быстродействие фреймворка, крайне низка(точнее в большинстве задач будет неважна), и тогда в этом случае вам может быть вообще не стоит использовать PHP. При использовании кэша и корректной настройки фреймворка(в документации есть небольшой раздел посещенный производительности), вряд ли будет ощютима разница м/у ZF и другими фреймворками.
Структура директорий
ZF — не накладывает никаких ограничений на структуру директорий. Да и вообще не диктует никаких жестких ограничений на разработчика, любые компоненты фреймворка можно использовать независимо.
Автозагрузка
Все необходимые классы грузятся автоматически, автозагрузка сделана на основе spl_autoload, вы можете настраивать стандартный автозагрузчик, или написать совой(вряд ли пригодится).
Роутер
Маршруты можно отключать, есть несколько стандартных маршрутизаторов(точнее шаблонов правил для маршрутизации), можно довольно удобно добавлять свои.
Контроллер
Префиксы — Controller и Action(можно изменить), есть поддержка модульности(объединения контроллеров в модули).
Отображение
Поддерживает layout'ы, view-helper'ы, встроенный view мне нравится, но можно подключать шаблонизатор.
Модель
Нет никаких ограничений на построение модели, есть свой класс для работы с БД, можно довольно удобно подключать ORM(Doctine, Propel).
Валидация форм
Огромные возможности для генерации и валидации форм или других данных.
Расширяемость
Уже писал об этом.
Хуки
Если под ядром иметь ввиду MVC, то можно создавать плагины для Front Controller'a, Action, классов для работы с БД, приложения.
Чего нет
Нет жестких правил для создания приложений, по сути объединять все компоненты фреймворка приходиться самому, хотя с приходом новых версий фреймворка(компонента Zend_Application) ситуация меняется.
Черт, забыл написать о том, что это↑ — немного информации о ZF.
Если под ядром иметь ввиду MVC, то можно создавать плагины для Front Controller'a, Action, классов для работы с БД, приложения.
Хуки в Ci существуют только потому, что bootstrap в CI определен зараннее, а bootstrap Zf разработчик может сам написать.
мне кажется, здесь есть некоторая двусмыслица — MVC в фреймворке это просто большой компонент, но никак не его основа или свойство. ZF это да, большой и даже просто отличный набор компонент, в числе которых есть и набор специфичных MVC-средств, правда, применение которых сразу диктует необходимость жестко следовать многочисленным правилам и писать очень много кода. То есть — если не использовать MVC — остальное это мощнейший набор компонент (например, все что Server — супер, рест и т.п., а Zend_Search_Lucene вообще уникальный в мире РНР компонент), иначе — привязка к одной идеологии. А так — мой любимейший инструмент (без MVC и форм, ну и без ORM в их понимании :)
P.S. Добавьте еще поддержку от лидера самого языка, а также наличие (если я верно помню) сертификации, интеграции с AJAX-фреймворком (при этом также самым мощным в мире интегрированным пакетом (Dojo, потому как jQuery, с которым также немного есть, все же просто либа с кучей плагинов, а не пакет).
P.S. Добавьте еще поддержку от лидера самого языка, а также наличие (если я верно помню) сертификации, интеграции с AJAX-фреймворком (при этом также самым мощным в мире интегрированным пакетом (Dojo, потому как jQuery, с которым также немного есть, все же просто либа с кучей плагинов, а не пакет).
Вы используете свою реализацию MVC?
нет, я не использую никакой :) очень нравиться своя архитектура (ну не своя, но реализация отличается от других немного) — signal/slot, о чем напишу на днях как раз
Это Observer? т.е. event-ы без предварительной регистрации? Вроде Drupal так устроен…
неа :) Я пишу статью, код (опен-сорс) уже почти готов, последние штрихи — в течении недели будет выложен и написана подробная статья.
Занятно… если верно помню, смысл singnal/slot или observer был в том, что любой компонент может без предварительной регистрации послать любой event. И любой же компонент может любой event отработать. Если в данном случае что-то иное, то скорее всего это не signal/slot…
немного не так, вернее — не совсем так. например, вполне могут быть ограничения на евенты (хотя, чтобы не путать, это все же не то, что принято понимать под events, например, в десктопных системах или JS).
Signal/Slot — это обобщенное название архитектуры, обсервер — это один из паттерной проектирования, реализующий модель событий и подписок. А вот реализации всего этого в «железе» то бишь коде и привязке его к задачам — это может выйти совсем иное. В общем, вряд ли сейчас стоит затевать большую дисскуссию, скоро будет возможность обсудить и практически «пощупать» код и подход.
Signal/Slot — это обобщенное название архитектуры, обсервер — это один из паттерной проектирования, реализующий модель событий и подписок. А вот реализации всего этого в «железе» то бишь коде и привязке его к задачам — это может выйти совсем иное. В общем, вряд ли сейчас стоит затевать большую дисскуссию, скоро будет возможность обсудить и практически «пощупать» код и подход.
Почему-то все разработчики, голосующие за ZF в один голос твердят, что свобода Zend — это плюс. Мой опыт показывает, что это очень и очень сильное заблуждение. Вы когда пишете проект на ZF, неужели директории проекта раскидываются как попало и то же происходит с именами в СУБД и коде? Врядли. Значит правила все-таки есть. Почему бы не дать другим ребятам придумать их за вас? Все-равно это просто семантика. В который кстати автор приложения может что-то не додумать. А вот фреймворк, который в разработке 3-й год наверняка на этом уже обжегся.
Ruby on Rails так стремительно дорос до состояния, в котором уже показывает зубы PHP из-за гениального подхода Conventions over Configurations. Все работает из коробки, просто следуй правилам. И не делай одну и ту же работу дважды. А вот Zend из коробки не работает. Нет ее, коробки.
Я бы вообще, честно говоря, не стал Zend с Yii и CI сравнивать. Скорее с PEAR (/me уворачивается от кучи помидоров из зала): те же яйца, вид сбоку. И покрашены в цвета Enterprise.
И алаверды, он все-таки заметно медленнее конкурентов. Аргумент «хотите скорости берите асм» — ересь до тих пор, пока Zend продолжает сливать тому же Yii по критерию «это у меня в продакшне работает хорошо, а это медленно».
Ruby on Rails так стремительно дорос до состояния, в котором уже показывает зубы PHP из-за гениального подхода Conventions over Configurations. Все работает из коробки, просто следуй правилам. И не делай одну и ту же работу дважды. А вот Zend из коробки не работает. Нет ее, коробки.
Я бы вообще, честно говоря, не стал Zend с Yii и CI сравнивать. Скорее с PEAR (/me уворачивается от кучи помидоров из зала): те же яйца, вид сбоку. И покрашены в цвета Enterprise.
И алаверды, он все-таки заметно медленнее конкурентов. Аргумент «хотите скорости берите асм» — ересь до тих пор, пока Zend продолжает сливать тому же Yii по критерию «это у меня в продакшне работает хорошо, а это медленно».
Я сразу хочу попросить не реагировать на последний абзац как на красную тряпку. Это субъективное мнение и личный опыт. У меня он работал медленно, но поднимать тесты и доказывать это мне лень. За весь остальной базар отвечу ;].
Я от Zend-а как от full stack фреймворка именно поэтому отказался (может сейчас там всё лучше… не знаю). А вот как Enterprise-версию PEAR использую его с большим удовольствием.
Такое впечатление что вы работали с zend по принципу «установил-запустил-удалил».
«Значит правила все-таки есть. Почему бы не дать другим ребятам придумать их за вас?»
zf.sh create project quickstart — создаётся структура «придуманная ребятами за вас»
А вот Zend из коробки не работает.
Опять-же zf.sh create project quickstart. После этого появляются конфиги, прописыватся основные контроллеры, бутстрап, ну а сайт отзывается при заходе на главную страницу, ну что ещё нужно?
«И алаверды, он все-таки заметно медленнее конкурентов.»
Даже если это и так (хотя насколько я помню symphony был «заметно медленнее конкурентов»), то я не понимаю, какая разница если на продакшне будет стоять кеширование? И да, за всё своё время работы с Zf, да и Php вовсе, он НИКОГДА не был «бутылочным горлышком» приложения, обычно 70-80% времени генерации страницы занимают запросы к БД.
И да, по сравнению с конкурентами (пробовал Symphony и Cake), только у него действительно чистый, профессионально написанный код и красивая архитектура. Лучше только питоновский Джанго :)
«Значит правила все-таки есть. Почему бы не дать другим ребятам придумать их за вас?»
zf.sh create project quickstart — создаётся структура «придуманная ребятами за вас»
А вот Zend из коробки не работает.
Опять-же zf.sh create project quickstart. После этого появляются конфиги, прописыватся основные контроллеры, бутстрап, ну а сайт отзывается при заходе на главную страницу, ну что ещё нужно?
«И алаверды, он все-таки заметно медленнее конкурентов.»
Даже если это и так (хотя насколько я помню symphony был «заметно медленнее конкурентов»), то я не понимаю, какая разница если на продакшне будет стоять кеширование? И да, за всё своё время работы с Zf, да и Php вовсе, он НИКОГДА не был «бутылочным горлышком» приложения, обычно 70-80% времени генерации страницы занимают запросы к БД.
И да, по сравнению с конкурентами (пробовал Symphony и Cake), только у него действительно чистый, профессионально написанный код и красивая архитектура. Лучше только питоновский Джанго :)
Я его серьезно ковырял только первый раз. И время от времени теперь ставлю как-раз по описанному Вами принципу ;]. И раз такой способ есть и он кому-то удобен, значит они на правильном, на мой взгляд, пути. Клево.
«Профессионально написаный код» (никак не могу удержать от улыбки) — результат работы ограниченной команды людей. Посмотрите Yii. В нем пока тоже все хорошо. Таков мир, когда код пишет миллион людей, он за крайне редким исключением выглядит плохо.
А вот в случае зенда за это приходится расплачиваться ОЧЕНЬ низкой скоростью разработки. Мир вымрет пока они сделают full-stack. Вспомните за какой срок были созданы рельсы. И они все еще впереди планеты всей в вопросе «мы делаем вашу жизнь лучше и разработку проще». И PHP вообще ничем ответить не может :[.
Но самое страшное, что в Zend нет ВООБЩЕ ничего сложного. Одна из самых страшных задач фреймворка — удобный ORM. Потому что это один из 3-х китов. Это вам не классики-врапперы для SMTP-функций писать. Еще и поэтому его код _пока_ хорош.
«Профессионально написаный код» (никак не могу удержать от улыбки) — результат работы ограниченной команды людей. Посмотрите Yii. В нем пока тоже все хорошо. Таков мир, когда код пишет миллион людей, он за крайне редким исключением выглядит плохо.
А вот в случае зенда за это приходится расплачиваться ОЧЕНЬ низкой скоростью разработки. Мир вымрет пока они сделают full-stack. Вспомните за какой срок были созданы рельсы. И они все еще впереди планеты всей в вопросе «мы делаем вашу жизнь лучше и разработку проще». И PHP вообще ничем ответить не может :[.
Но самое страшное, что в Zend нет ВООБЩЕ ничего сложного. Одна из самых страшных задач фреймворка — удобный ORM. Потому что это один из 3-х китов. Это вам не классики-врапперы для SMTP-функций писать. Еще и поэтому его код _пока_ хорош.
Что-то с моей речью в последнее время. То, что в Zend нет сложных сущностей — это не страшно. Это просто объясняет успех с кодом :].
«результат работы ограниченной команды людей»
Насколько я понимаю, вы предполагаете что framework пишется исключительно командой Zend? Это не так, более половины компонентов ZF разработанны их коммюнити, людьми которые не имеют никакого отношения к Зенду.
framework.zend.com/wiki/display/ZFPROP/Home
Насколько я понимаю, вы предполагаете что framework пишется исключительно командой Zend? Это не так, более половины компонентов ZF разработанны их коммюнити, людьми которые не имеют никакого отношения к Зенду.
framework.zend.com/wiki/display/ZFPROP/Home
Вы изменили мое отношение к этому фреймворку. Видимо за последнее время он действительно сильно развился. Если они тоже идут к Conventions over Configurations, набирают скорость и при этом умудряются качественно мейнтейнить код, за ними будущее. Обязательно копну его снова поглубже в ближайшее время, спасибо.
А ну и тогда некорректно писать, что в Zend правил нет. Понятно, что их можно нарушить. Но это верно для любого фреймворка. Даже в, упоминаемых мной почти в каждом комменте этой ветки, рельсах ;].
Не умер, просто вы не видите пока всей теневой работы над CI 2.0 что ведётся для развития EE и думаю к октябрю мы всё увидим
Прошел год.
Версия 2.0 не вышла.
К октябрю какого года вы имели ввиду? 2011-го? :D
Версия 2.0 не вышла.
К октябрю какого года вы имели ввиду? 2011-го? :D
Проблема CI в том что он разрабатывается под нужны компании-родителя, а не под нужны сообщества разработчиков.
Это разве плохо если они обкатают его на себе, так ведь и Rails создавался.
А дальше проблемы форкнуть проекта не стоит, можно.
А дальше проблемы форкнуть проекта не стоит, можно.
Уже давно форкнули. Получились Kohana и Kohana2.
Я в курсе, еще со времен истории с BlueFlame так как слежу за коммунити, но ни тот, ни другой не могут похвастаться таким сообществом, а главное хорошей и доступной документацией.
Хотя на данный момент я не сильно ожидаю CI2, так как занимаю разработкой своего форка 2ой версии и так сказать «папа» этих клонов RoR меня всецело засасывает всё больше :)
Хотя на данный момент я не сильно ожидаю CI2, так как занимаю разработкой своего форка 2ой версии и так сказать «папа» этих клонов RoR меня всецело засасывает всё больше :)
маленькая опечаточка....«myCoolAction() » — «actionMyCool()».
О ссылочке на сравнение производительности фреймворков, где Yii всех рулит. Ну сколько тыщ мильёнов раз можно повторять, что нельзя тестировать фреймворки на задаче Hello, World?!
Не надо грязи: абстрактно тестировать фреймворки — это все равно, что гоняться на лошадках-скакалках, корректно. Но в объяснительной, непосредственно перед описанием теста по этой самый ссылочке русским английским написано, что это всего-лишь тест bootstrap'а. И вот то, как эффективно фреймворк способен не загружать лишнего протестировать можно. Там же видно какое влияние это оказывает при наличии кэшера.
Извините, первое предложение я совсем не понял. Что касается объема bootstrap'a, то с каких пор это стало потребительской характеристикой фреймворка? Это все равно что судить о максимальной скорости автомобиля по объему его двигателя (да-да, у Белаза большой движок — он быстрее!).
То как отрабатывает bootstrap для hello world показывает насколько фреймворк способен не тянуть за собой всякую ненужную функциональность. Это всего одна из кучи характеристик фреймворка. Не самая важная, но и не бесполезная: объем двигателя косвенно определяет расход бензина. Так вот там по ссылочке они четко дают понять, что сравнивают не скорость фреймворка. А скорость бутстрапа.
В итоге же фреймворки выбираются по набору характеристик. Из которых часть вообще жутко субъективная и сравнению не подлежит. Другую часть можно и надо тестировать. При этом, понятно, что это не цельное сравнение одного фреймворка с другим.
В итоге же фреймворки выбираются по набору характеристик. Из которых часть вообще жутко субъективная и сравнению не подлежит. Другую часть можно и надо тестировать. При этом, понятно, что это не цельное сравнение одного фреймворка с другим.
Ну я недавно начал изучать php и фреймворк codeigniter но я его установил на php 5.3 там всего пару строчек надо поменять и 2 функции поменять
Наверно лучше было бы сравнить не с CodeIgniter а с Kohana.
Kohana сделана на основе его, с учетом ошибок допущенных в CodeIgniter, и с использованием PHP 5. Ну и сам проект поживее чем CodeIgniter, так что особого смысла просто в CodeIgniter я не вижу.
Вот небольшое сравнение CI с Zend и Kohana
stackoverflow.com/questions/282884/have-you-switched-from-codeigniter-to-kohana/395776#395776
И вот просто CI и Kohana
onwired.com/blog/exploring-kohana-as-an-alternative-to-codeigniter/
Kohana сделана на основе его, с учетом ошибок допущенных в CodeIgniter, и с использованием PHP 5. Ну и сам проект поживее чем CodeIgniter, так что особого смысла просто в CodeIgniter я не вижу.
Вот небольшое сравнение CI с Zend и Kohana
stackoverflow.com/questions/282884/have-you-switched-from-codeigniter-to-kohana/395776#395776
И вот просто CI и Kohana
onwired.com/blog/exploring-kohana-as-an-alternative-to-codeigniter/
Есть подозрения (основанные на материалах блога), что автор не хочет связываться с Kohana из-за плохого (особенно на фоне CI) состояния документации. ;)
Именно.
Да, codeigniter делает всех по документации. Переводы на русский регулярно обновляются. Сейчас доступны даже для версии codeigniter 2.0.0
Kohana уже очень отдалённо напоминает CI. Под капотом всё другое…
Много воды. Yii хорош в первую хочередь очень приятным внутренним дизаином, без костылей для поддержки php4.
«Также в Yii нет хелперов в том виде, который был в CI, но ничто не запрещает их
реализовать… или позаимствовать, например, из Kohana.» — откровенно предвзятое сранение, к тому же что в игниторе, что в кохане хелперы ужасны.
«Также в Yii нет хелперов в том виде, который был в CI, но ничто не запрещает их
реализовать… или позаимствовать, например, из Kohana.» — откровенно предвзятое сранение, к тому же что в игниторе, что в кохане хелперы ужасны.
Спасибо, познавательно. Я бы в обзор ещё добавил бы библиотеки/расширения их число (хотя бы порядок) и полезность.
По сути Yii (он же «Ы») мало чем отличается, судя по твоем описанию, от CI, да CI медленно растет и фиксит старые баги, к тому же у тех, кто с ним относительно много работал, черепная коробка упирается в потолок, там многого не достает из нужного (та же капча по стандарту, а не из вики, проблемы с рерайтами — nginx/lighttpd не поддерживает всяких .htaccess, приходится править конфиги, а на хостинге это не очень удобно), и много лишнего (тот же FTP, Template parser, HTML table, Cart).
Да и у многих встает нужда поюзать либы CI в консольном или кроновом приложении, а это ой как тяжело, гляньте хотя бы статью в вики…
CI нужен хороший форк, эдакий CI 2.0
Да и у многих встает нужда поюзать либы CI в консольном или кроновом приложении, а это ой как тяжело, гляньте хотя бы статью в вики…
CI нужен хороший форк, эдакий CI 2.0
Про представления и отсутствие layouts в CI подмечено верно. Но есть хорошее решение проблемы — библиотека «Template».
По поводу костылей, подобных MY_<библиотека> в CI — в точку. Когда требуется 2-х или 3-х уровневое наследование, это является проблемой.
Да, в CI напрочь отсутствует ORM, в то же время в Yii она работает очень быстро.
Добавлю еще, что в CI вообще не предусмотрена система RBAC (Role-based Access Control), хотя и не отрицаю того, что при желании можно реализовать самостоятельно.
Плюс ко всему в CI стандартная библиотека для работы с сессиями Session имеет два режима работы — хранения данных в базе и… в куках. Да-да, именно в куках. А не в сессиях.
По поводу костылей, подобных MY_<библиотека> в CI — в точку. Когда требуется 2-х или 3-х уровневое наследование, это является проблемой.
Да, в CI напрочь отсутствует ORM, в то же время в Yii она работает очень быстро.
Добавлю еще, что в CI вообще не предусмотрена система RBAC (Role-based Access Control), хотя и не отрицаю того, что при желании можно реализовать самостоятельно.
Плюс ко всему в CI стандартная библиотека для работы с сессиями Session имеет два режима работы — хранения данных в базе и… в куках. Да-да, именно в куках. А не в сессиях.
Скаффолдинг в Yii есть. Через консоль делается crud для любой модели и получаем желаемое
Нереально крутой плюс Yii — адекватный автор. После первого же указания на небольшую потерю производительности в ActiveRecord, он пошел и запатчил его в новой ветке лично. Хотя я обещал прислать патч. А еще мы скоро туда им зашлем поддержку Шардинга для того же ORM и View на Dwoo с хелперами под рельсы. И все это в виде дополнений. Не нужно оно никому, оно даже не загрузится.
Им бы распиариться чуть-чуть и выдержать наплыв пионэров, которые при такой социальности автора могут быстро там дров наломать. И все будет тип-топ.
Им бы распиариться чуть-чуть и выдержать наплыв пионэров, которые при такой социальности автора могут быстро там дров наломать. И все будет тип-топ.
P.S. «Не нужно оно никому, оно даже не загрузится.» означает, что если модуль не нужен, он не будет грузиться. А не то, что эти модули вообще никому не нужны и никогда не загрузятся. ;]
Тикеты про шардинг читал :)
Dwoo… может сразу Quicky?
Dwoo… может сразу Quicky?
Единственное что мне не сильно понравилось в Yii это особые требования к ПО, PDO и именно 5.2, с 5.1 у фреймфорка небольшие трудности но решаемые, по крайней мере те которые мне пришлось встретить.
С помощью расширения можно обойти надобность в PDO, есть его эмулятор. Радует то что над фреймворком постоянно ведутся работы.
Есть уже несколько блогов русскоязычных посвященных этому фрейворку. Но документация хромает, часто приходится за элементарными вещами лезть в API.
Перешел с фреймворка CodeIgniter на Yii. И на сколько понял то основная активная масса тоже их CodeIgniter.
С помощью расширения можно обойти надобность в PDO, есть его эмулятор. Радует то что над фреймворком постоянно ведутся работы.
Есть уже несколько блогов русскоязычных посвященных этому фрейворку. Но документация хромает, часто приходится за элементарными вещами лезть в API.
Перешел с фреймворка CodeIgniter на Yii. И на сколько понял то основная активная масса тоже их CodeIgniter.
Уже около полугода сижу на Ы, до этого юзал CI, поэтому статья заинтересовала. Спасибо, обзор с моим мнением полностью совпадает, могу подписаться под всеми пунктами, а лично хочу отметить один крупный плюс Ы — это личное общение с самим автором на форуме — по первому требованию он исправляет ошибки, а также достаточно быстро отвечает на любые вопросы, это круто! А большой минус лично для меня — крайне неудобная документация, за что был отмечен CI, у него и правда поудобнее было это дело организовано.
Сейчас в состоянии перехода с CI на Yii — для нового проекта нужно был фреймворк, понял, что CI каким бы родным он не был — устарел. Посмотрел несколько штук, глянул Yii и понял, что это то что нужно.
Конечно, хотелось бы прозрачной документации как в CI с примерами использования (ибо не всегда с первого раза можно въехать :) ), но это дело наживное.
Конечно, хотелось бы прозрачной документации как в CI с примерами использования (ибо не всегда с первого раза можно въехать :) ), но это дело наживное.
Если основной документации не хватит — есть ещё некоторое количество рецептов тут: http://yiiframework.ru/doc/cookbook/ru/index
Всё = всё, что потребуется из указанных в конфигурации путей в указанном порядке.
> что мешает в CI не работать с базой в модели
Мешает странный API. Если не передать третьему параметру false при загрузке модели — произойдёт инициализация БД.
Про MY_ вы не так поняли. В CI можно было перекрыть класс ядра только один раз и только с одним определённым именем. Отсюда многочисленные одноимённые классы с разным функционалом в wiki и на форумах.
> что мешает в CI не работать с базой в модели
Мешает странный API. Если не передать третьему параметру false при загрузке модели — произойдёт инициализация БД.
Про MY_ вы не так поняли. В CI можно было перекрыть класс ядра только один раз и только с одним определённым именем. Отсюда многочисленные одноимённые классы с разным функционалом в wiki и на форумах.
Я не про новые библиотеки, а про перекрытие стандартных. Например, нужно для email организовать очередь, а не отправлять сразу. Код уже написан. Что делать?
Вот тут я описал как перекрывается CWebUser: http://yiiframework.ru/doc/cookbook/ru/access.rbac.file.
Троллевидный коммент. Почему не использовать фреймворк только из за одной этой детали.
Из мануала:
Note: If $_SESSION (or $HTTP_SESSION_VARS for PHP 4.0.6 or less) is used, use unset() to unregister a session variable, i.e. unset ($_SESSION['varname']);.
Что лишний раз показывает — пути ПХП неисповедимы.
P.S. Сам я в глаза Yii не видел.
Из мануала:
Note: If $_SESSION (or $HTTP_SESSION_VARS for PHP 4.0.6 or less) is used, use unset() to unregister a session variable, i.e. unset ($_SESSION['varname']);.
Что лишний раз показывает — пути ПХП неисповедимы.
P.S. Сам я в глаза Yii не видел.
«Валидатор в Yii на голову опережает CodeIgniter.»
в Yii весь функционал на голову опережает Igniter. это не сравнимые фреймворки, разного уровня.
а дополнительные модули для отправки почты — это не обязательно. такие мелочи самому можно сделать.
главное — архитектура. а она в Yii очень грамотно спроектирована. создатель Yii ещё на Prado собаку съел :-)
кстати, с недавних пор существует англоязычная группа поддержки пользователей Yii в Google Groups.
в Yii весь функционал на голову опережает Igniter. это не сравнимые фреймворки, разного уровня.
а дополнительные модули для отправки почты — это не обязательно. такие мелочи самому можно сделать.
главное — архитектура. а она в Yii очень грамотно спроектирована. создатель Yii ещё на Prado собаку съел :-)
кстати, с недавних пор существует англоязычная группа поддержки пользователей Yii в Google Groups.
Статья какая то предвзятая. Жаль.
Хм… приведите доводы, которые опровергают статью.
То, что CodeIgniter перешел из фазы активного роста в фазу эволюционного развития мне кажется скорее плюсом.
А огромное комьюнити, гигантское количество библиотек и наработок, стабильность, чистота исходного кода и вылизанность документации против более гибкой модели контроллеров, работы из консоли, зависимости от версии PHP и одного единственного разработчика?
Для меня выбор очевиден.
«Короля делает его окружение», а как раз окружения yii и не хватает. Однако об этом в татье упомянуто как то вскользь…
Зато нет конфликтов при расширении классов и запуске в кроне… Не знаю, у меня и CI отлично работает в кроне и никаких конфликтов с классами не замечено. Get разрешил, там где это было необходимо простым разрешением символов "?=" в config… Включенный по дефолту jquery? Я те скрипты, которые мне необходимы и там, где мне это нужно. View слабый? Не знаю, меня устраивает. Вобщем изложенные проблемы мне кажутся довольно надуманными, а наличие каких то фишек, которых нет в базовой поставке CI? Так боюсь размера топика не хватит для перечисления половины фишек-расширений для CI.
Выбор делайте сами.
А огромное комьюнити, гигантское количество библиотек и наработок, стабильность, чистота исходного кода и вылизанность документации против более гибкой модели контроллеров, работы из консоли, зависимости от версии PHP и одного единственного разработчика?
Для меня выбор очевиден.
«Короля делает его окружение», а как раз окружения yii и не хватает. Однако об этом в татье упомянуто как то вскользь…
Зато нет конфликтов при расширении классов и запуске в кроне… Не знаю, у меня и CI отлично работает в кроне и никаких конфликтов с классами не замечено. Get разрешил, там где это было необходимо простым разрешением символов "?=" в config… Включенный по дефолту jquery? Я те скрипты, которые мне необходимы и там, где мне это нужно. View слабый? Не знаю, меня устраивает. Вобщем изложенные проблемы мне кажутся довольно надуманными, а наличие каких то фишек, которых нет в базовой поставке CI? Так боюсь размера топика не хватит для перечисления половины фишек-расширений для CI.
Выбор делайте сами.
Да, еще в Yii есть такие замечательные вещи, как «поведения» — Behaviors. По сути — это те же интерфейсы для моделей, но именно реализация подобной системы поведений и вообще их существование — просто шедевр.
Сравнение хорошее, сам пишу в CI, но и параллельно гляжу на YII, но у последнего плохая и сухая документация, сложно входить.
1. Что бесит пока в YII это «верблюжий» синтаксис, от которого я со времен MFC как-то отошел к GNU C варианту.
2. В CI проще писать название экшена как просто метод класса function index() в YII добавляется к чему-то function actionIndex() лишнее имхо
3. В YII много всяческих статических обрещений к классам YII:: и моделям
4. Много не нужного в начальной генерации приложения, авторизация, ACL… всё это все равно под себя переписывается :)
1. Что бесит пока в YII это «верблюжий» синтаксис, от которого я со времен MFC как-то отошел к GNU C варианту.
2. В CI проще писать название экшена как просто метод класса function index() в YII добавляется к чему-то function actionIndex() лишнее имхо
3. В YII много всяческих статических обрещений к классам YII:: и моделям
4. Много не нужного в начальной генерации приложения, авторизация, ACL… всё это все равно под себя переписывается :)
>>2. В CI проще писать название экшена как просто метод класса function index() в YII добавляется к чему-то function actionIndex() лишнее имхо
Все публичные методы контроллера, имеющие префикс «action», доступны для вызова напрямую uri. Если Вы хотите написать свои публичные методы, но не хотите, чтобы они так вызывались — убираете префикс и все.
>>3. В YII много всяческих статических обрещений к классам YII:: и моделям
Это действительно плохо?
>>4. Много не нужного в начальной генерации приложения, авторизация, ACL… всё это все равно под себя переписывается
Отключите в конфиге и будет Вам счастье. Пользуюсь Yii с версии 1.0.2 и пока что ничего не приходилось переписывать под себя, хотя постоянно использую RBAC и другие компоненты.
Все публичные методы контроллера, имеющие префикс «action», доступны для вызова напрямую uri. Если Вы хотите написать свои публичные методы, но не хотите, чтобы они так вызывались — убираете префикс и все.
>>3. В YII много всяческих статических обрещений к классам YII:: и моделям
Это действительно плохо?
>>4. Много не нужного в начальной генерации приложения, авторизация, ACL… всё это все равно под себя переписывается
Отключите в конфиге и будет Вам счастье. Пользуюсь Yii с версии 1.0.2 и пока что ничего не приходилось переписывать под себя, хотя постоянно использую RBAC и другие компоненты.
1. Это я знаю, но зачем лишние буквы action? В CI это решалось _index() и вуа-ля, а уж если YII претендует только на поддержку PHP 5 то и private|protected в путь.
2. Это не плохо, но просто идеологически не красиво, есть god объект, а тут еще кучка статиков, get_instance() например как-то идеологически красивее.
3. Понятно что отключить и отрезать можно всё, по статье просто генератор из консоли не так уж и не обходим, так как генерит кучу лишнего мусора на начальном этапе, приходится отключать. Авторизацию и права я переписал, ACL в YII в таком виде мне лично просто неудобен.
2. Это не плохо, но просто идеологически не красиво, есть god объект, а тут еще кучка статиков, get_instance() например как-то идеологически красивее.
3. Понятно что отключить и отрезать можно всё, по статье просто генератор из консоли не так уж и не обходим, так как генерит кучу лишнего мусора на начальном этапе, приходится отключать. Авторизацию и права я переписал, ACL в YII в таком виде мне лично просто неудобен.
2 Мрак999:
про п.1 и п.2
Попробуйте перейти на нормальный редактор, жизнь покажется другой :-)
про п.1 и п.2
Попробуйте перейти на нормальный редактор, жизнь покажется другой :-)
спасибо, но Net Beans меня вполне устраивает как и PHP Expert Editor, а вот читать лишнее я не люблю, как и писать идеологически не правильно, имхо
В моем редакторе есть такие прекрасные вещи как Bundles…
я набираю три буквы act и наживаю кнопку tab.
в результате у меня уже написан метод, остается еще раз таб нажать что бы выделилось желаемое имя экшена и все.
и т.д… не знаю есть ли такое в тех редакторах что Вы используете.
А если Вас коробит внешний вид методов начинающихся со слова action, то я Вам скажу что когда их больше чем два, это удобнее чем просто наименование, т.к. сразу видно кто и где… и даже в Вашем редакторе наверняка есть список ф-ций который можно отсортировать по алфавиту, и тогда еще в более удобном виде можно сразу отделить все методы, которые являются экшенами…
Кстати из-зв своего редактора я отказался от всяких ИДЕ и оченб рад тому :-)
P.S. не спора ради.
я набираю три буквы act и наживаю кнопку tab.
в результате у меня уже написан метод, остается еще раз таб нажать что бы выделилось желаемое имя экшена и все.
и т.д… не знаю есть ли такое в тех редакторах что Вы используете.
А если Вас коробит внешний вид методов начинающихся со слова action, то я Вам скажу что когда их больше чем два, это удобнее чем просто наименование, т.к. сразу видно кто и где… и даже в Вашем редакторе наверняка есть список ф-ций который можно отсортировать по алфавиту, и тогда еще в более удобном виде можно сразу отделить все методы, которые являются экшенами…
Кстати из-зв своего редактора я отказался от всяких ИДЕ и оченб рад тому :-)
P.S. не спора ради.
Я вам про то, что это мусор и лишнее, что например хорошо решили в CI, думаю согласитесь, что _ короче чем action. Меня не коробит писать лишнее, мне неудобно читать лишнее.
Рад за вас и ваш редактор.
P.S. какой спор, я просто говорю, что лучше реализовано в CI, вот и всё.
Рад за вас и ваш редактор.
P.S. какой спор, я просто говорю, что лучше реализовано в CI, вот и всё.
Так подчеркивание в ЦИ делает же метод недоступным напрямую из урла (если мне память не изменят).
а в Ы для этого вообще ничего не нужно писать :-))))))
Но мысль я Вашу понял.
а в Ы для этого вообще ничего не нужно писать :-))))))
Но мысль я Вашу понял.
public function indexAction () { }
vs
public function _index () { }
Первая однозначно лучше, так как следует правилам хорошего тона, которые гласят что название функции должно объяснять своё предназначение или как-то так.
vs
public function _index () { }
Первая однозначно лучше, так как следует правилам хорошего тона, которые гласят что название функции должно объяснять своё предназначение или как-то так.
Для CI тут верно будет сравнивать без «_» т.к. у метода с «_» несколько другой смысл.
public function indexAction () { }Вот так, ага.
vs
public function index () { }
public function index () { }И вот так мы делаем index приватным в обоих фреймворках. Скажите, подчеркивание слабо объясняет, что метод приватный и недоступен для url?
vs
public function _index () { }
Очень слабо.
Бред это все!
Это не критерий качества, это не минус и не плюс это не влияет на производительсно, это в принципе не влияет на скорость набора, на читаемость кода (т.к. эта вещь вообще может быть чисто субъективной) полный бред! Бросьте Вы, спорить из-за ерунды!
то что Yii реально перспективнее чем Ci даже спорить нечего (мы говорим о текущих публичных версиях, и особенно о том что идет из «коробки»)
Это не критерий качества, это не минус и не плюс это не влияет на производительсно, это в принципе не влияет на скорость набора, на читаемость кода (т.к. эта вещь вообще может быть чисто субъективной) полный бред! Бросьте Вы, спорить из-за ерунды!
то что Yii реально перспективнее чем Ci даже спорить нечего (мы говорим о текущих публичных версиях, и особенно о том что идет из «коробки»)
В NetBeans аналогичный функционал имеется.
Интересное сравнение… Да, CI стар, я бы даже сказал — суперстар.
Касаемо сравнения хотелось бы добавить, что встроенные шаблонизаторы в принципе не особо актуальная вещь — похапе сам себе шаблонизатор, зачем использовать что-то еще — усложнять?
CI нравится синтаксисом — порог входа низкий, не нужно сильно много вникать в логику, представленную разработчиком.
'нет консоли' — а это действительно актуально?
Надо бы ZF посмотреть…
Касаемо сравнения хотелось бы добавить, что встроенные шаблонизаторы в принципе не особо актуальная вещь — похапе сам себе шаблонизатор, зачем использовать что-то еще — усложнять?
CI нравится синтаксисом — порог входа низкий, не нужно сильно много вникать в логику, представленную разработчиком.
'нет консоли' — а это действительно актуально?
Надо бы ZF посмотреть…
phpBB пишут новый форум на PHP6, несмотря на то, что ему до стабильности еще далеко. А кто-то еще пишет новые проекты на CI мне этого не понять никогда.
CI вообще какое то гавно, а не фреймворк — нет даже элементарной поддержки авторизации и контроля доступа.
Почитал про Yii, попробовал создать бложик по туториалу, вроде бы не плохой фреймворк, но размер смущает.
Cakephp при той же функциональностьи всего 2мегабайта, а Yii — 6 мегабайт.
Почитал про Yii, попробовал создать бложик по туториалу, вроде бы не плохой фреймворк, но размер смущает.
Cakephp при той же функциональностьи всего 2мегабайта, а Yii — 6 мегабайт.
CodeIgniter очень хорош для определённого круга задач.
Размер ни на что не влияет.
Размер ни на что не влияет.
для какого рода задач?
Например, чтобы написать нечто легковесное, где кеш нежелателен.
как вы считаете www.mirovoefoto.ru это легковесное? :)
Там наверняка и кеш есть и всё-всё ;)
ну наверное :) кэш как мне кажется не главное тут чтобы можно было назвать приложение «легким» или «тяжелым» плане.
CI даёт хороший инструмент, придерживаясь его правил можно писать, что угодно, он структурирует, настраивает на свод лад мыслей. Есть конечно архитектурные неудачи для своего времени это было видимо необходимо. Но они решаемые с помощью расширения стандартных же классов.
CI даёт хороший инструмент, придерживаясь его правил можно писать, что угодно, он структурирует, настраивает на свод лад мыслей. Есть конечно архитектурные неудачи для своего времени это было видимо необходимо. Но они решаемые с помощью расширения стандартных же классов.
Вы не правы, CI делает свою работу и делает её очень хорошо — он облегчают рути и работу PHP программиста, так же помогает структурировать код и ускорить процесс совместной разработки.
Это же каркас приложения, всё равно авторизацию писать надо самому, это не так сложно. Контроль доступа так же надо писать самому, и что из этого, что нет в стандартной поставке? В любом случае я еще не видел этих моментов, когда не приходилось бы переписывать.
Ну и разумеется в wiki у CI всё это есть и авторизации (freakauth и еще парочка) и ACL и даже как прикрутить за пару минут Zend'овские библиотеки
Это же каркас приложения, всё равно авторизацию писать надо самому, это не так сложно. Контроль доступа так же надо писать самому, и что из этого, что нет в стандартной поставке? В любом случае я еще не видел этих моментов, когда не приходилось бы переписывать.
Ну и разумеется в wiki у CI всё это есть и авторизации (freakauth и еще парочка) и ACL и даже как прикрутить за пару минут Zend'овские библиотеки
спасибо, с сегодняшнего дня начну изучать yii :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Сравнение Yii с CodeIgniter