Комментарии 18
Название статьи слишком претензионное. Не находите?
Наверное правильнее все-таки было бы — «Существует ли идеальный php фреймворк?», либо «В поисках идеального php фреймворка»
с таким названием статьи, не боитесь за свою карму?
> В связи с чем стоит вопрос, стоит ли работать над полным обновлением фреймворка для нашего проекта?
Вам не лучше написать в Q&A?
> В связи с чем стоит вопрос, стоит ли работать над полным обновлением фреймворка для нашего проекта?
Вам не лучше написать в Q&A?
:) Да. Такая идея в названии публикации: Идеальный PHP фреймворк (поиск его). Почему Codeigniter (стоит его заменить на другой)?
А суть вопроса заключается в некоторых проблемах, а это Сложности:
— Придется переписывать все с нуля;
— Смена инструмента для разработчика требует времени;
— Не факт, что результат перехода будет удовлетворительным и что сократиться количество кода;
А суть вопроса заключается в некоторых проблемах, а это Сложности:
— Придется переписывать все с нуля;
— Смена инструмента для разработчика требует времени;
— Не факт, что результат перехода будет удовлетворительным и что сократиться количество кода;
В который раз обламываюсь: вижу заголовок статьи на интересную для меня тему про CI, а внутри вместо интересных решений, классов, библиотек и моделей нахожу графики сравнения… Например так: продолжать ли работу в CI? Недавно перед нами была поставлена задача (краткое описание), мы ее стали решать так (кратко описание, пример кода), но обломались вот тут (описание, код). В другом фреймфорке мы применили метод (код, описание)… и так далее. С удовольствием изучил бы такой материал.
> Если обобщить, то команда из десяти человек могла бы доработать Codeigniter в этом плане за месяц, при таком ресурсе сообщества фреймворк более чем перспективен.
Если будет обратная совместимость — тогда ок. Но если доработки будут ломать обратную совместимость, тогда со всеми «костылями» доработанный CI != существующему CI. По сути будет являться новым фреймверком.
Возможно, я ошибаюсь.
Если будет обратная совместимость — тогда ок. Но если доработки будут ломать обратную совместимость, тогда со всеми «костылями» доработанный CI != существующему CI. По сути будет являться новым фреймверком.
Возможно, я ошибаюсь.
Кеширования с возможностью изменения бекендов(File, Memcache, etc...);
— Zend_Cache прикручивается за 10 минут к CI
Разделение прав доступа
— Что именно? В базовом виде для админки настраивается за час
Моделей
— А здесь что?
— Zend_Cache прикручивается за 10 минут к CI
Разделение прав доступа
— Что именно? В базовом виде для админки настраивается за час
Моделей
— А здесь что?
Моделей
— А здесь что?
Вы работали с Yii? Модели в CI — это, ну в общем, не модели, а так жалкое подобие того как можно работать с ними в Yii. кодигнайтероввские модели со скрипом можно подтянуть по возможностям сторонними приблудами, но с риском что при следующем обновлении фреймворка все поломается. Правда, для таких ситуаций есть утешений, учитывая что фреймворк обновляется раз пару лет, то таких сложностей можно и не боятся :D
Работал и не полон радостных впечатлений. Вот что именно из моделей YII вам так нравится? В отличие от CI, конечно же
Хм, мне скорее непонятно что может нравится в CI-моделях, может что-то за последнее время поменялось, но насколько помню там же вообще ничего не было. В Yii мне нравятся события, ORM, генерация моделей, scopes.
В принципе их даже сравнивать нельзя. Это же разные весовые категории. Модели в CI — это попытка сделать букву M в MVC для тех кто не осилил ООП. Что-то типа бейсика, если переводить на языки программирования, такая себе обучалка. Но после него нужно браться за более приспособленные к работе вещи.
Сам был в своё время поклонником CI, несколько проектов на нём, но и мой уровень как программера тогда был ниже. Когда попробовал Yii, то понял, что тот выше на голову и при этом не такой замудренный как Simfony (тут уже у меня мозгов не хватило, хотя и видел моменты по которым этот фреймворк превосходит Yii).
Просто то, что на CI пишется 2 недели на Yii можно за день сделать.
В принципе их даже сравнивать нельзя. Это же разные весовые категории. Модели в CI — это попытка сделать букву M в MVC для тех кто не осилил ООП. Что-то типа бейсика, если переводить на языки программирования, такая себе обучалка. Но после него нужно браться за более приспособленные к работе вещи.
Сам был в своё время поклонником CI, несколько проектов на нём, но и мой уровень как программера тогда был ниже. Когда попробовал Yii, то понял, что тот выше на голову и при этом не такой замудренный как Simfony (тут уже у меня мозгов не хватило, хотя и видел моменты по которым этот фреймворк превосходит Yii).
Просто то, что на CI пишется 2 недели на Yii можно за день сделать.
:) Имея нужные вещи под рукой, на CI скорость разработки не уступает YII, а вот монструозности в виде доппрослоек (ORM), скоупов и прочих крайне «веселят» в отладке, когда сайт задыхается под нагрузкой. Я сегодня-завтра выложу статью по поводу CI, у нас есть внутренняя разработка для задолбавшихся поддерживать код на разных CMS и монструозных фреймворках, хотим выложить в паблик
Ну так я выше написал, что сторонними приблудами можно CI довести до нормального уровня, но зачем? Если это уже есть в Yii.
И в Yii хочешь используй ORM, хочешь не используй. В общем нам друг друга, наверное, не понять. :)
И в Yii хочешь используй ORM, хочешь не используй. В общем нам друг друга, наверное, не понять. :)
Я говорю о том, что мне CI нравится возможностью расширять или нет по желанию и аскетичной пустотой из коробки, добавляешь только то, что нужно в конкретной задаче и очень легко. А YII и Zend – из коробки монстры и код, поневоле, тоже начинает становится монструозным.
Это как коробочные редакции CMS – в них входит дофига и еще немножко из того, что в конкретном сайте нафиг не нужно
Это как коробочные редакции CMS – в них входит дофига и еще немножко из того, что в конкретном сайте нафиг не нужно
Ну значит у нас разные подходы :) Я стараюсь сделать быстрее, а потом уже убирать лишнее, все равно всегда наперед не узнаешь, что не так будет.
А вот переживать, что при очередном обновлении фреймворка что-то поломается из-за использования сторонних библиотек — это уже для меня не подходит. Yii даёт хороший костяк, на который так же хорошо ложатся сторонние вещи.
В Yii мне как раз не хватает такой универсальности, чтобы не писать новый код на каждый чих, а была основа и можно было заниматься бизнес-логикой, а не писать по сути свой фреймворк.
Также кэш какой-то недоделанный в CI. В общем, я в свое время с CI спрыгнул и рад :) Хотя на одной из конференций по Simfony защищал его даже, но время идет, люди меняются.
А вот переживать, что при очередном обновлении фреймворка что-то поломается из-за использования сторонних библиотек — это уже для меня не подходит. Yii даёт хороший костяк, на который так же хорошо ложатся сторонние вещи.
В Yii мне как раз не хватает такой универсальности, чтобы не писать новый код на каждый чих, а была основа и можно было заниматься бизнес-логикой, а не писать по сути свой фреймворк.
Также кэш какой-то недоделанный в CI. В общем, я в свое время с CI спрыгнул и рад :) Хотя на одной из конференций по Simfony защищал его даже, но время идет, люди меняются.
Можно пример, когда сайт «задыхается» под нагрузкой применимо к Yii и его ORM?
Вопрос папе-программисту:
— Папа, почему солнце восходит на востоке, а заходит на западе?
— Сынок, работает — не трогай.
Если есть работающий продукт, который пользуется определенным спросом и у которого есть комьюнити — резонный вопрос: «Зачем?»
Если разработкой движка занимается небольшая команда — сможет ли она вести одновременно два, по сути, разных продукта.
Имхо, лучше новый продукт выпустить, а за тем переманить аудиторию на новый движок разработав надежное средство миграции. Хотя в маркетинге я не особо разбираюсь, что бы такое советовать.
З.Ы.: Сам использую Yii. А вот свободное время собираюсь пощупать Nette PHP — не как альтернативу, а как платформу в которой, по отзывам, есть интересные решения.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Стоит ли продолжать работу с CodeIgniter в существующем проекте?