Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 136
(В PHP не смог разместить из-за отстутствия кармы)
Ну вот вам +
поддержу, уже 10.00
Автор, собственно, хотел написать всего лишь «hello world».
Но начинать с чего-то нужно. Кроме того, насколько я понял из статьи, автор и собирается реализовать некое относительно серъезное приложение на каждом их фреймворков.
В оригинале, на странице блога автора есть такое:
Part II will be the result of my experience as I use each framework to write a prototype for my real-world application.
В оригинале, на странице блога автора есть такое:
Part II will be the result of my experience as I use each framework to write a prototype for my real-world application.
страшно подумать, что бы он написал про ZF
интересно, чем обосновывается выбор фремворков для сравнения?
Я не в плане. что критикую, на самом деле интересно.
За статЬю спасибо — очень познавательно.
Я не в плане. что критикую, на самом деле интересно.
За статЬю спасибо — очень познавательно.
CakePHP один из самых первых фреймворков, CI && Yii имеют общего автора.
CodeIgniter разработан компанией EllisLab, а также Риком Эллисом (Rick Ellis) и Полом Бурдиком (Paul Burdick). Yii Framework же разработан китайцем Qiang Xue.
к слову заметить что это китаец кторый живет в калифорини еще являтся автором замечательного фреймворка — клона ASP.NET — Prado, дядя он толковый и Yii получился на славу. Но канечно блогер что сравнвавший фреймвокри действительно не хотел вдавться в Cake, он просто сделал выбор и решил в письменной форме его утвердить для себя самого.
На сайте Yii Framework есть сравнения производительности не только с Zend и подобными :)
>* CakePHP требует создания модели, базы данных и таблицы, даже если они не используются в вашей программе.
Неверно, не требует, а предполагает, при необходимости модели и таблицы можно и не создавать. Насчет БД вообще не уверен
>* Cake сам вызывает представление автоматически, основываясь на имени контроллера. В CI и Yii вы вызываете представление явно, поэтому у Cake соглашения более преобладают над конфигурацией. В свою очередь, в CI и Yii вы можете вызывать несколько представлений.
В Кейке никто не запрещает отменить вывод представления, или рендерить конкретное, а также несколько
>Оба используют шаблон MVC, но не кажутся очень строгими в этом плане. CakePHP намного больше зависит от соглашений, чем Yii и CI.
Для кого-то строгость недостаток, для кого-то преимущество. А вообще заметил такую особенность при изучении CI и CakePHP после «трупхп» (не то что MVC, а даже простого отделения бизнес-логики нет, не взирая на использование шаблонизаторов) — те, кто сначала разберется с кейком (а порог вхождения у него действительно выше), потом пишут понятный код на CI, а вот если наоборот, то в коде CI бывает очень сложно разобраться. Ладно с моделями, когда модель выполняет только функцию обертки для БД, а в контроллерах, например, вычисляется FirstName+' '+LastName, но вот когда начинают (а начинают часто)в контроллерах собирать виды из «кусочков» (открывающий тег html в одном файле, закрывающий в другом) то сложновато поддерживать такой код
Неверно, не требует, а предполагает, при необходимости модели и таблицы можно и не создавать. Насчет БД вообще не уверен
>* Cake сам вызывает представление автоматически, основываясь на имени контроллера. В CI и Yii вы вызываете представление явно, поэтому у Cake соглашения более преобладают над конфигурацией. В свою очередь, в CI и Yii вы можете вызывать несколько представлений.
В Кейке никто не запрещает отменить вывод представления, или рендерить конкретное, а также несколько
>Оба используют шаблон MVC, но не кажутся очень строгими в этом плане. CakePHP намного больше зависит от соглашений, чем Yii и CI.
Для кого-то строгость недостаток, для кого-то преимущество. А вообще заметил такую особенность при изучении CI и CakePHP после «трупхп» (не то что MVC, а даже простого отделения бизнес-логики нет, не взирая на использование шаблонизаторов) — те, кто сначала разберется с кейком (а порог вхождения у него действительно выше), потом пишут понятный код на CI, а вот если наоборот, то в коде CI бывает очень сложно разобраться. Ладно с моделями, когда модель выполняет только функцию обертки для БД, а в контроллерах, например, вычисляется FirstName+' '+LastName, но вот когда начинают (а начинают часто)в контроллерах собирать виды из «кусочков» (открывающий тег html в одном файле, закрывающий в другом) то сложновато поддерживать такой код
добавлю от себя:
>Использование: Helpers, Actions, Behaviours, Layouts, Components… Неужели я должен знать обо всем этом чтобы написать мою программу?
а чего хотели то? фреймворк или либу? Если писать хеловорды, то конечно ниче учить не надо.
>я столкнулся с проблемой (404 error) и это не было описано в документации. Мне пришлось подредактировать файлы .htacces, чтобы решить это.
автор — слепой, ибо это описано
>В случае CakePHP оказалось очень тяжело обнаружить, какие же файлы оформления использовались.
действительно, не прочитав документацию… очень сложно понять, что надо поменять /views/loayouts/default.ctp
>Результат: CodeIgniter и Yii оба выглядят более гибкими. На данным момент я не могу определить, какой из них более гибкий.
автор, читайте доки… кейк расширяем по самое не могу
>Быстрый тест: я не заметил явного пути, как усилить стойкость паролей. В туториале сказано, что если вы будете хешировать пароли самостоятельно, то приложение не будет работать.
автор, курите доки… Auth Component делает засоленные пароли на основе самой стойкой хеш функции, которая есть у вас в пхп + соль берется из Security.salt, котрая указывается в в конфиге. мало того, если надо, можно отнаследоваться от стандартного компонента и реализовать свою функцию хеширования, пароливания:)
вывод:автор —мудакне читает доки, просто не хотел даже разбираться
>Использование: Helpers, Actions, Behaviours, Layouts, Components… Неужели я должен знать обо всем этом чтобы написать мою программу?
а чего хотели то? фреймворк или либу? Если писать хеловорды, то конечно ниче учить не надо.
>я столкнулся с проблемой (404 error) и это не было описано в документации. Мне пришлось подредактировать файлы .htacces, чтобы решить это.
автор — слепой, ибо это описано
>В случае CakePHP оказалось очень тяжело обнаружить, какие же файлы оформления использовались.
действительно, не прочитав документацию… очень сложно понять, что надо поменять /views/loayouts/default.ctp
>Результат: CodeIgniter и Yii оба выглядят более гибкими. На данным момент я не могу определить, какой из них более гибкий.
автор, читайте доки… кейк расширяем по самое не могу
>Быстрый тест: я не заметил явного пути, как усилить стойкость паролей. В туториале сказано, что если вы будете хешировать пароли самостоятельно, то приложение не будет работать.
автор, курите доки… Auth Component делает засоленные пароли на основе самой стойкой хеш функции, которая есть у вас в пхп + соль берется из Security.salt, котрая указывается в в конфиге. мало того, если надо, можно отнаследоваться от стандартного компонента и реализовать свою функцию хеширования, пароливания:)
вывод:автор —
А как Вас на хабр пустили? или всем приятно читать откровенный бред?
это как тебя сюда пустили, если уж на то пошло:
для тех, кто не понял — автор не написал тут _ничего_ полезного, при этом позволяет себе судить о том, кому быть тут, а кому нет
Не соглашусь, я уже знаю основной для меня недостаток Yii :)
эм… я имел в виду автора комментария:)
PS какой же?
PS какой же?
Торможу… тяпница… пиво… :)
Он предполагает прямой вызов вида из контроллера и очевидно допускает (об этом сказано в статье напрямую) сборку в контроллере html кода из нескольких шаблонов, то есть реализацию логики представления на уровне логики приложения. Имхо, это не способствует написанию «хорошего» кода.
Он предполагает прямой вызов вида из контроллера и очевидно допускает (об этом сказано в статье напрямую) сборку в контроллере html кода из нескольких шаблонов, то есть реализацию логики представления на уровне логики приложения. Имхо, это не способствует написанию «хорошего» кода.
ну… в каке тоже можно такое делать, если захотеть, но соглашусь
Можно, но как раз для этого нужно «рыться» в документации :) Я не один раз видел разницу между кодом, написанным человеком, который сначала осваивал CI (а судя по статье он очень схож с Yii в этом отношении), а потом Cake и наоборот. Если сначала человек изучал кейк, а потом Ci/Kohana, то он в них старается эмулировать layout. А если CI сначала (особенно если PHP первый язык и о «всяких» MVC представления нет), то начинает собирать из «хидеров/футеров» и в нем.
Может любители CI/Kohana/Yii со мной не согласятся, но, имхо, в среде PHP-фреймворков CI и его потомки занимают тоже место, что и сам PHP среди других языков для сервер-сайд веб-разработки. Низкий порог вхождения, но провоцирует появление «быдлокодеров» — бесконтрольная свобода часто превращается в анархию :)
Может любители CI/Kohana/Yii со мной не согласятся, но, имхо, в среде PHP-фреймворков CI и его потомки занимают тоже место, что и сам PHP среди других языков для сервер-сайд веб-разработки. Низкий порог вхождения, но провоцирует появление «быдлокодеров» — бесконтрольная свобода часто превращается в анархию :)
из своего опыта:
cakephp предоставляет некую гибкость. обший шаблон (или как хотите — layout) в контроллере легко заменить на нужный ( $this->layout =… ). если проект работает с ajax — нужно дописывать колбеки AppController::beforeFilter() ( ну или AppController::afterFilter() ), которые перекодировуют содержимое в нужной кодировке. ( был случай, когда сайт таки работал на cp1251, но нужно было ajax использовать ).
о моделях:
для нужной можели можно и переопределить поведение. с легкостью можно преобразовать результирующий набор под свои нужды (например автоматизировать работу с изображениями для всех моделей, включая обработчик загрузки изображения, уменьшение и т.д.). Одним из плюсов (хотя ето может быть и минусом) cake'а есть то, что каждая выборка подхватывает все связанные данные — orm включена по дефолту. к моделям можно подцепить Behaviour, но…
о производительности:
прозводительность кейка на самом деле хромает…
«Helpers, Actions, Behaviours, Layouts, Components… Неужели я должен знать обо всем этом чтобы написать мою программу?»
helpers — нужны, но не всегда и не все. для общих нужд достаточно только двух: Html & Form. остальные можно отключить (но надо лезть в ядро...).
behaviours — расшырения модели. для прироста производительности функционал можно переносить в AppModel и ее наследниц. ефект приблизительно тот же.
components — расшырения контроллеров. для прироста производительности функционал можно переносить в AppController.
нужен некий прирост производительности: убирается ненужное. на свой страх и риск.
опять же — каждый проект имеет свои нужды
cakephp предоставляет некую гибкость. обший шаблон (или как хотите — layout) в контроллере легко заменить на нужный ( $this->layout =… ). если проект работает с ajax — нужно дописывать колбеки AppController::beforeFilter() ( ну или AppController::afterFilter() ), которые перекодировуют содержимое в нужной кодировке. ( был случай, когда сайт таки работал на cp1251, но нужно было ajax использовать ).
о моделях:
для нужной можели можно и переопределить поведение. с легкостью можно преобразовать результирующий набор под свои нужды (например автоматизировать работу с изображениями для всех моделей, включая обработчик загрузки изображения, уменьшение и т.д.). Одним из плюсов (хотя ето может быть и минусом) cake'а есть то, что каждая выборка подхватывает все связанные данные — orm включена по дефолту. к моделям можно подцепить Behaviour, но…
о производительности:
прозводительность кейка на самом деле хромает…
«Helpers, Actions, Behaviours, Layouts, Components… Неужели я должен знать обо всем этом чтобы написать мою программу?»
helpers — нужны, но не всегда и не все. для общих нужд достаточно только двух: Html & Form. остальные можно отключить (но надо лезть в ядро...).
behaviours — расшырения модели. для прироста производительности функционал можно переносить в AppModel и ее наследниц. ефект приблизительно тот же.
components — расшырения контроллеров. для прироста производительности функционал можно переносить в AppController.
нужен некий прирост производительности: убирается ненужное. на свой страх и риск.
опять же — каждый проект имеет свои нужды
совет: HtmlHelper::link() использует много ресурсов, если его заменить на обычные ссылки — почувствуете некую разницю во времени. (при условии если в view много $html->link )
взято из
codesith.blogspot.com/2007/09/cakephp-performance-tuning.html
groups.google.com/group/cake-php/browse_thread/thread/1eab831f222d195a
взято из
codesith.blogspot.com/2007/09/cakephp-performance-tuning.html
groups.google.com/group/cake-php/browse_thread/thread/1eab831f222d195a
тоже думаю, что в продакшн версии нужно много конструкций $html->method() и $form->method() позаменять на их html output.
дествительно, если в форме 10 инпут-текст-полей, зачем 10 раз дергать метод $form->text(some_field_d, ....)
если взять да и заменить на
<input type=«text» name=«date[Model][SomeFieldN]» ....>
дествительно, если в форме 10 инпут-текст-полей, зачем 10 раз дергать метод $form->text(some_field_d, ....)
если взять да и заменить на
<input type=«text» name=«date[Model][SomeFieldN]» ....>
не-не-не, дэвид блейн. их не затем писали, чтобы вы заменяли их на что-то другое. $html->link автоматически поддерживает reverse routing и в зависимости от прописанных маршрутов сам создаст нужную ссылку. а $form поддерживает подписывание форм компонентом Security, а также занимается всякими другими полезными вещами типа вывода сообщений валидатора. но если это все не нужно, то можно конечно =)
не, я же говорю про $form->text() а не про $form->input(). Последний конечно же занимается и сообщениями валидатора и сотворением лейблов.
а вместо $html->link() писать заведомо ведомый с уже известными в продакшене роутами.
Естественно не поголовно все менять, а только ту часть которая будет всегда статической :)
Но это конечно, если руки дойдут…
а вместо $html->link() писать заведомо ведомый с уже известными в продакшене роутами.
Естественно не поголовно все менять, а только ту часть которая будет всегда статической :)
Но это конечно, если руки дойдут…
если делать $html->link('qwe', '/foo/bar') — ест меньше, насколько я помню
поддерживаю
автор протестировал очень поверхностно, основываясь на собственных придуманных и непонятных тест-кейсах. Кому нужно тестировать hello world? Да, кейк медленне, но напиши-те ка каркас социальной сети, у которой в бд будут присутствовать множество связанных таблиц, и повыгребать это нс CI или Yii, и вы хорошенько подолабетесь по выгребанию этих «гребанных»(пардон) связанных записей. Кейк с этим справляется, а код — довольно понятный. Даже не то что довольно понятный, а совсем понятный, можно хорошо проследить логику. Даст автору CI такие возможности?
Топик следовало назвать «Сравнение производительности фреймворков на приложении „hello world!“»
автор протестировал очень поверхностно, основываясь на собственных придуманных и непонятных тест-кейсах. Кому нужно тестировать hello world? Да, кейк медленне, но напиши-те ка каркас социальной сети, у которой в бд будут присутствовать множество связанных таблиц, и повыгребать это нс CI или Yii, и вы хорошенько подолабетесь по выгребанию этих «гребанных»(пардон) связанных записей. Кейк с этим справляется, а код — довольно понятный. Даже не то что довольно понятный, а совсем понятный, можно хорошо проследить логику. Даст автору CI такие возможности?
Топик следовало назвать «Сравнение производительности фреймворков на приложении „hello world!“»
шо опять?
сто тысяч миллионов раз уже обсуждалось почему сравнение фреймворков не имеет смысла на уровне приложений уровня хелловорлд.
codeigniter не использую, поэтому сказать ничего не могу, но в cakephp вы не разбираетесь совсем и документацию даже не читали. зачем например вам понадобился RewriteBase? защита от кражи куки обеспечивается в компоненте Session, а csrf — в Security. и тд и тп.
стыдно, товарищ.
сто тысяч миллионов раз уже обсуждалось почему сравнение фреймворков не имеет смысла на уровне приложений уровня хелловорлд.
codeigniter не использую, поэтому сказать ничего не могу, но в cakephp вы не разбираетесь совсем и документацию даже не читали. зачем например вам понадобился RewriteBase? защита от кражи куки обеспечивается в компоненте Session, а csrf — в Security. и тд и тп.
стыдно, товарищ.
В CI тоже куки защищаются в сессиях
«сто тысяч миллионов раз уже обсуждалось почему сравнение фреймворков не имеет смысла на уровне приложений уровня хелловорлд.»
Проблема в том чтобы найти человека, у которого хватит времени и сил на то, чтобы хорошо разобраться в существующем многообразии фреймворков. Вы можете дать ссылку на статью от такого человека? Я бы с удовольствием ее прочитал(можно и на английском).
Кстати, вы заметили что это перевод? =)
Проблема в том чтобы найти человека, у которого хватит времени и сил на то, чтобы хорошо разобраться в существующем многообразии фреймворков. Вы можете дать ссылку на статью от такого человека? Я бы с удовольствием ее прочитал(можно и на английском).
Кстати, вы заметили что это перевод? =)
не разбираешься — не пиши, что я тут могу сказать. а вообще если это перевод, то можно любую ахинею переводить что ли?
Дык а вседаки вы можете дать ссылку на правильную, по вашему, статью о сравнение фреймворков? Если нет, то уж лучше это, чем совсем ничего. Как иначе узнать, что лучше то(понятно, что нужно пробовать самому, но это довольно сложно и на мой взгляд не очень осуществимо)?
«а вообще если это перевод, то можно любую ахинею переводить что ли?»
Нет, но не стоит ведь путать автора и переводчика. И про перевод я написал главным образом потому, что для меня является удивительным как можно прочитать статью и не заметить, что она лишь переведена, а не написана =)
«а вообще если это перевод, то можно любую ахинею переводить что ли?»
Нет, но не стоит ведь путать автора и переводчика. И про перевод я написал главным образом потому, что для меня является удивительным как можно прочитать статью и не заметить, что она лишь переведена, а не написана =)
У меня есть идея написать некое реальное приложение на нескольких фреймворках, потихоньку ее реализую, было бы уже почти готово (хотел сравнивать только 4 PHP фреймворка, но открыл для себя руби и питон, надо освоить рельсы и джанго, жду очередных капель и унций :) ). Другое дело, что любое сравнение будет некорректно в конкретных условиях. Знаю, например, что многие не реализуют в CI/Kohana паттерн декоратора (layout в кейке, симфони, руби...), а собирают вид по частям из хидеров/футеров. Я так писать не буду, но наверняка кто-то придерется
А еще есть Java :) Если действительно будете писать статью с охватом php, python и ruby, то добавьте сайт ostov.org (там сейчас нет ничего) в закладки. Я сейчас разрабатываю фреймворк на основе Tapestry5, Hibernate и еще множестве других подфреймворков. И помогу вам с этой статьёй, всё что касается Java и Ostov :)
человек просто не хотел разбираться нормально в cake.
Может в кейке он и не разобрался, но CI лучше:)
ну не надо холиварить… нравиться — пишите. А вообще каждый фреймворк — под определенную задачу.
Оо еще один защитник своей конфетки, ну нравится так и пишите, что любите Cake.
А насчет «каждый фреймворк — под определенную задачу» — мягко говоря это не совсем так.
А насчет «каждый фреймворк — под определенную задачу» — мягко говоря это не совсем так.
я не защитник. Я противник холиваров. А на сами фреймворки мне посрать — мы пишем так вообще на своём.
ошибаетесь.
вот, например, для helloworld вообще по сути не нужен никакой фреймворк
нет ничего универсального
вот, например, для helloworld вообще по сути не нужен никакой фреймворк
нет ничего универсального
Согласен, но как это связано с тем что я выше написал.
Я бы все фрэймворки PHP разделил на 3 группы
1) Комбайны, которые все могут и для них миллион дополнений: ZEND
2) Популярные, которые много могут: CI, Cake, и еще несколько
3) И так мелкие, малоизвестные, бажные: основная масса PHP фрэймворков.
Ну так вот мы либо пишем на чистом PHP, Либо если хотим использовать что-то сложное, большое и знаем что это есть в зенде — используем зенд.
Если не боимся фрэймворков, то любой сайт(web-приложение) можно писать на любом фрэймвоке из второй группы, и здесь абсолютно по барабану на каком именно из них(в об этом то я и писал комментарием выше).
А третья группа просто просто для неопытных программистов, либо для тех кто и писал эти недофрэймворки. Со временем, развиваясь, конечно, экземпляры третьей группы могут попасть во вторую.
Я бы все фрэймворки PHP разделил на 3 группы
1) Комбайны, которые все могут и для них миллион дополнений: ZEND
2) Популярные, которые много могут: CI, Cake, и еще несколько
3) И так мелкие, малоизвестные, бажные: основная масса PHP фрэймворков.
Ну так вот мы либо пишем на чистом PHP, Либо если хотим использовать что-то сложное, большое и знаем что это есть в зенде — используем зенд.
Если не боимся фрэймворков, то любой сайт(web-приложение) можно писать на любом фрэймвоке из второй группы, и здесь абсолютно по барабану на каком именно из них(в об этом то я и писал комментарием выше).
А третья группа просто просто для неопытных программистов, либо для тех кто и писал эти недофрэймворки. Со временем, развиваясь, конечно, экземпляры третьей группы могут попасть во вторую.
Значит еще один минус в сторону cake, так как старт на нем будет намного медленнее чем на других фреймворках при сравнении приложений хелловорлд, а если уже говорить о полноценном сравнении то читаем habrahabr.ru/blogs/php/50341/#comment_1331982
Я не знаю что Вы имели ввиду, но может сначала надо было бы разобраться в CakePHP.
И вообще. как можно о(б)суждать тО, чего не знаете?
Извините, но то что Вы написали про CakePHP — это бред!
И вообще. как можно о(б)суждать тО, чего не знаете?
Извините, но то что Вы написали про CakePHP — это бред!
Справедливости ради — вообще-то это перевод, о чем сказано и в первых строках поста, и в последних :)
Хочу заметить, что это всего лишь перевод статьи Daniel Carrera.
На мой вгляд, статья писалась не с задачей развить новый холивар, а просто показать миру новый фреймворк.
Да, возможно автор оригинала и преувеличил некоторые моменты и не разобрался во всех тонкостях CI и CakePHP. Тут уже судить более опытным адептам религий CakePHP && CI.
Тем не менее, думаю Yii Framework имеет право на существование и своё достойное место.
На мой вгляд, статья писалась не с задачей развить новый холивар, а просто показать миру новый фреймворк.
Да, возможно автор оригинала и преувеличил некоторые моменты и не разобрался во всех тонкостях CI и CakePHP. Тут уже судить более опытным адептам религий CakePHP && CI.
Тем не менее, думаю Yii Framework имеет право на существование и своё достойное место.
Поддерживаю мнение, высказанное bethrezen ниже — статья просто предлагает ознакомиться с Yii, как новым фреймворком, показав, что в нем уже имеется на данный момент.
Естественно, ничего не утверждается окончательно и бесповоротно — автор и сам говорит, что не писал ничего серъезного ни на одном из указанных фреймворков.
Просто Yii — очень свеженький фреймворк, и и информации по нему пока почти нет, а тем более на русском языке. Я поэтому и решил перевести статью — у людей будет больше информации и возможности с ним ознакомиться -> больше людей попробуют/выскажут мнение/доработают код. В итоге получим более качественный и функциональный фреймворк, с большим комьюнити =)
Естественно, ничего не утверждается окончательно и бесповоротно — автор и сам говорит, что не писал ничего серъезного ни на одном из указанных фреймворков.
Просто Yii — очень свеженький фреймворк, и и информации по нему пока почти нет, а тем более на русском языке. Я поэтому и решил перевести статью — у людей будет больше информации и возможности с ним ознакомиться -> больше людей попробуют/выскажут мнение/доработают код. В итоге получим более качественный и функциональный фреймворк, с большим комьюнити =)
… высказанное bethrezen *выше*…
Буквально несколько часов назад qiang поблагодарил всех добровольцев, согласившихся переводить документацию. Она будет доступна с версии 1.0.2, запланированную на 1 февраля.
Комьюнити совсем скоро уже сделает свой первый осознанный и крепкий вдох :)
Думаю дифицита различной объективной информации уже не будет.
Комьюнити совсем скоро уже сделает свой первый осознанный и крепкий вдох :)
Думаю дифицита различной объективной информации уже не будет.
а что Зенд Ф. уже не считается одним из самых популярных фреймуорков, я бы с большим удовольствием почитал именно о нём.
В качестве FW он тяжеловат. Но его можно растащить на компоненты. В Сети много материалов как прикрутить его к тому же CodeIgniter, у которого библиотека слабовата.
Вы имеете в виду реализацию MVC?? Характеристика «тяжеловат», сами понимаете, сильно зависит от ситуации и не является критерием для отсева.
P.S. И коль уж назвались «сравнением»:
Цель любого такого сравнения — помочь человеку определиться, что ему выбрать из многообразия имеющихся инструментов. Исключая из сравнения продукты далеко не аутсайдерские (Symfony & ZF) автор (ИМХО) оказывает в каком-то смысле медвежью услугу.
P.S. И коль уж назвались «сравнением»:
Цель любого такого сравнения — помочь человеку определиться, что ему выбрать из многообразия имеющихся инструментов. Исключая из сравнения продукты далеко не аутсайдерские (Symfony & ZF) автор (ИМХО) оказывает в каком-то смысле медвежью услугу.
Жрет ресурсы.
Разработчику надо самому определяться. На то он и разработчик.
К слову:
Недавно мне дали один крупный проект. Отдельно руководством выделялось время, чтобы конкретно я решал между ZF и Symphony. Прямое сравнение фреймворков определило всего лишь последовательность, в которой мне самому уже приходилось разбираться со всеми необходимыми для проекта тонкостями.
Было желание написать данный проект на Yii, но руководство запретило из идеалогических соображений. В результате я выбрал Symphony.
Так что, если есть возможность выбора — лучше самому вникнуть и решить.
К слову:
Недавно мне дали один крупный проект. Отдельно руководством выделялось время, чтобы конкретно я решал между ZF и Symphony. Прямое сравнение фреймворков определило всего лишь последовательность, в которой мне самому уже приходилось разбираться со всеми необходимыми для проекта тонкостями.
Было желание написать данный проект на Yii, но руководство запретило из идеалогических соображений. В результате я выбрал Symphony.
Так что, если есть возможность выбора — лучше самому вникнуть и решить.
а на нем у автора helloworld не запустился вообще
Полезный материал, спасибо
А помоему эта статья была проплачена тому забугорному блогеру. У них это нормальная практика. И платил однозначно Yii.
У меня аналогичная точка зрения, у Yii всё отлично, а у других проблемы имеются.
Видимо не захотели освещать другие стороны.
Видимо не захотели освещать другие стороны.
Уй действительно оч. хорош. Он намного проще Cake в изучении и намного богаче CodeIgniter'а по функционалу. Если бы пришлось выбирать сейчас — выбрал бы его. А так жалко наработки бросать.
А статья — бяка.
А статья — бяка.
Огромное! огромное! огромное! спасибо! Я новичок в РНР, всегда хотел увидеть сравнение РНР-фреймворков, что бы выбрать лучший!
Советую посмотреть еще как минимум в сторону Zend Framework и symfony. Да и от CakePHP не отказываться только на основании этого обзора. А как новичку лично я бы порекомендовал symfony или CakePHP (в них сложнее, имхо, написать «плохой» код), а уж потом разбираться с CI и пр.
это не та статья, на которую можно полагаться в выборе фреймворка
Все фреймворки поставляются с дефолтным оформлением и CSS. В целях тестирования мне пришлось избавляться от этого, чтобы каждый фреймворк делал только то, что требуется. Вот зачем было повторять эту фразу? Или это чтобы окончательно убедить читающих, что все фреймворки поставляются с дефолтным оформлением и CSS. В целях тестирования мне пришлось избавляться от этого, чтобы каждый фреймворк делал только то, что требуется? Если второй вариант, то теперь я точно знаю, что все фреймворки поставляются с дефолтным оформлением и CSS. В целях тестирования мне пришлось избавляться от этого, чтобы каждый фреймворк делал только то, что требуется.
О Пирожке:
Простота — проблем с установкой не возникло, написал блог пример за 10 минут. Все зависит от «сервера» :))
Документация — хромает на обе ноги, это го не скрыть (на дворе 1.3, а все доки о 1.1), дельных советов мало :(
Производительность — мне кажется на мелких проектах, роли вообще не играет, заметно быстрее Зенда
Гибкость — есть магия, и она просто супер, но блин пока в неё вникнешь, нужно много выкурить манов и нервов :) Дальше хуже когда начинаешь работать со сложными БД, там все связать уже проблема, вся красота куда-то прячется. Работа с массивами отдельный респект. Обертки тоже очень помогают!
Контроль доступа — полный провал, разобраться во встроенном так и не получилось, писал свой
О «Безопасности» тяжело сказать, её реализация на стандартном уровне (может ниже), в зенде гораздо выше
Разработка и поддержка — складывается впечатление что о нём только говорят, но ничего для него не делают, а если делает, то 1-2 дня в месяц :(
Простота — проблем с установкой не возникло, написал блог пример за 10 минут. Все зависит от «сервера» :))
Документация — хромает на обе ноги, это го не скрыть (на дворе 1.3, а все доки о 1.1), дельных советов мало :(
Производительность — мне кажется на мелких проектах, роли вообще не играет, заметно быстрее Зенда
Гибкость — есть магия, и она просто супер, но блин пока в неё вникнешь, нужно много выкурить манов и нервов :) Дальше хуже когда начинаешь работать со сложными БД, там все связать уже проблема, вся красота куда-то прячется. Работа с массивами отдельный респект. Обертки тоже очень помогают!
Контроль доступа — полный провал, разобраться во встроенном так и не получилось, писал свой
О «Безопасности» тяжело сказать, её реализация на стандартном уровне (может ниже), в зенде гораздо выше
Разработка и поддержка — складывается впечатление что о нём только говорят, но ничего для него не делают, а если делает, то 1-2 дня в месяц :(
ну а Symfony уже устарел? можно было его включить в обзор.
А ао существу — так я вообще непонимаю для чего тесты проводить фреймворка, который только «Hello world» показывает?!
Прелести фреймворков совсем в другом, а для этого теста нужно было использовать CMS.
А ао существу — так я вообще непонимаю для чего тесты проводить фреймворка, который только «Hello world» показывает?!
Прелести фреймворков совсем в другом, а для этого теста нужно было использовать CMS.
CodeIgniter имеет возможность работать с так названными «подготовленными выражениями» (prepared statements). В случае с CodeIgniter они называются Query Bindings и справляются со своей задачей потрясающе.
А еще там есть такая замечательная вещь, как ActiveRecords, которой я не пользуюсь :)
А еще там есть такая замечательная вещь, как ActiveRecords, которой я не пользуюсь :)
Спасибо за обзор
хоть и выглядит как галопом по европам, но достаточно познавательно, было бы интересно чтобы не флейм начался, а кто-нибудь появился и рассказал про Yii, как он в проектах, скорость разработки и есть ли острые углы.
А почему ни кто не упомянул про Kohana? kohanaphp.com/ habrahabr.ru/blogs/kohanaphp/
Наша контора в начала сидела на КИ, но потому перешли на Kohana. Работаем уже больше года.
Очень очень положительные впечателения. Все прелести CI + плюшки
* не поодерживается php4 а значит на всю катушку используется фичи php5
* очень продуманая и гибкая архитектура. если припрет можно переопределить почти все системные библиотеки
* действительно качественный код
Сообщество пока что меньше, чем у кейка или CI но вышеописанные фичи с лихвой окупают это
Наша контора в начала сидела на КИ, но потому перешли на Kohana. Работаем уже больше года.
Очень очень положительные впечателения. Все прелести CI + плюшки
* не поодерживается php4 а значит на всю катушку используется фичи php5
* очень продуманая и гибкая архитектура. если припрет можно переопределить почти все системные библиотеки
* действительно качественный код
Сообщество пока что меньше, чем у кейка или CI но вышеописанные фичи с лихвой окупают это
Сравнение фреймворков, по хелло-вордам, напоминают сравнения машин, ударом ногой по бамперу.
ламерское сравнение :-) документация cakephp явно была просмотрена «по верхушкам», как говорится. и на основании это делаются какие-то выводы: ну вы даёте.
про yii ничего не могу сказать, а codeigniter сильно не дотягивает до cakephp. хотя и быстрее. это единственное его преимущество.
про yii ничего не могу сказать, а codeigniter сильно не дотягивает до cakephp. хотя и быстрее. это единственное его преимущество.
По-моему, не затронули такую важную вещь как функциональность, наличие определенных компонентов по-умолчанию, за исключением контроля доступа.
У меня вопрос, если позволите. Кто из перечисленных умеет делать нормальный scaffolding чтобы использовать его как основу для бэкенда? Кекс вроде умеет, насколько знаю (джанго, рэйлс и его php вополщение «акелла», тоже).
Мда, автор явный новичек в плане использования php-фреймворков, а уже сравнивать пытается, неразобравшись толком.
я недавно сам провел тесты с «Hello World» между Kohana Codeigniter и Yii
если интересно welcome andrey.opeykin.ru/performance-kohana-codeigniter-yii/
если интересно welcome andrey.opeykin.ru/performance-kohana-codeigniter-yii/
Такое ощущение что автор изначально настроен против CakePHP.
Более того не указана версия и примеры тестов, чтобы любой мог их повторить.
Человек пишет нелепые вещи, например об авторизации, которая в cake делается с помощью Auth компонента в 5 строчек.
Естественно нужен некоторый порог вхождения, но через некоторое время работы с ним понимаешь, что те ограничения которые он накладавает дают гораздо больше преимуществ.
Да, порой нужно читать документацию, но согласитесь проще разобраться со средой в которой работаешь чем изобретать велосипед, как это приходится делать в CI.
А тесты от Yii это дейтвительно очковтирательство, чем автор это и поддтвердил.
Судя по фразе «CakePHP требует создания модели, базы данных и таблицы, даже если они не используются в вашей программе» я делаю вывод что тест автора для cake тоже не верен.
Достаточно указать $uses=array(); в контроллере и модель не будет создаваться.
далее я вижу фразу «Cake сам вызывает представление автоматически, основываясь на имени контроллера. В CI и Yii вы вызываете представление явно, поэтому у Cake соглашения более преобладают над конфигурацией. В свою очередь, в CI и Yii вы можете вызывать несколько представлений.»
И опять ошибка.
Ладно оставим это на совести автора, а статье — жирный минус.
Более того не указана версия и примеры тестов, чтобы любой мог их повторить.
Человек пишет нелепые вещи, например об авторизации, которая в cake делается с помощью Auth компонента в 5 строчек.
Естественно нужен некоторый порог вхождения, но через некоторое время работы с ним понимаешь, что те ограничения которые он накладавает дают гораздо больше преимуществ.
Да, порой нужно читать документацию, но согласитесь проще разобраться со средой в которой работаешь чем изобретать велосипед, как это приходится делать в CI.
А тесты от Yii это дейтвительно очковтирательство, чем автор это и поддтвердил.
Судя по фразе «CakePHP требует создания модели, базы данных и таблицы, даже если они не используются в вашей программе» я делаю вывод что тест автора для cake тоже не верен.
Достаточно указать $uses=array(); в контроллере и модель не будет создаваться.
далее я вижу фразу «Cake сам вызывает представление автоматически, основываясь на имени контроллера. В CI и Yii вы вызываете представление явно, поэтому у Cake соглашения более преобладают над конфигурацией. В свою очередь, в CI и Yii вы можете вызывать несколько представлений.»
И опять ошибка.
Ладно оставим это на совести автора, а статье — жирный минус.
Какая гадость. Какакя гадость эти дилетанские заметки в поисках дешевой популярности.
Может прежде чем переводить стоило разобраться насколько автор владеет вопросом?
Тем более он в первых строках вроде написал что НЕ разбирается ни в одном из представленных фреймворков, так что претензия в основном к переводчику. Я увидел просто какое то облако дезинформации, в котором даже копаться неприятно. Да, поначалу ещё более менее корректно сравнение качества документации и легкости установки. Это может сравнить и дилетант. Но дальше, дальше какие то голосовные выводу основанные на «насколько я знаю, как мне известно и т.д.» Не знаешь — не лезь.
CodeIgniter, например, просто повернут на безопасности. Причем включается она 2 словами в кофиге. True+True. Поле этого Боб не то что не получит запрос сервера о переводе 10000 долларов на сайт Евы. Боб даже не заметит что какой то *дак НАСТОЛЬКО банально пытался подсунуть ему дешевую ссылку.
Вобщем отвратительно.
Может прежде чем переводить стоило разобраться насколько автор владеет вопросом?
Тем более он в первых строках вроде написал что НЕ разбирается ни в одном из представленных фреймворков, так что претензия в основном к переводчику. Я увидел просто какое то облако дезинформации, в котором даже копаться неприятно. Да, поначалу ещё более менее корректно сравнение качества документации и легкости установки. Это может сравнить и дилетант. Но дальше, дальше какие то голосовные выводу основанные на «насколько я знаю, как мне известно и т.д.» Не знаешь — не лезь.
CodeIgniter, например, просто повернут на безопасности. Причем включается она 2 словами в кофиге. True+True. Поле этого Боб не то что не получит запрос сервера о переводе 10000 долларов на сайт Евы. Боб даже не заметит что какой то *дак НАСТОЛЬКО банально пытался подсунуть ему дешевую ссылку.
Вобщем отвратительно.
Не знаю, конечно, что автор подразумевал, когда писал о поддержке параметризированных запросов, но касаемо поддержки оных в CakePHP и CodeIgniter он явно поторопился.
CakePHP — Sanitize,
CodeIgniter — codeigniter.com/user_guide/database/queries.html
CakePHP — Sanitize,
CodeIgniter — codeigniter.com/user_guide/database/queries.html
Кстати, я сообщил автору о переводе его статьи и он поглядывает сюда, и даже хотел бы поучаствовать в дискуссии:
Wow. Thanks. I'm very glad to see the article being used. I see a lot of comments too on your post. I read them with Google Translate. A lot of the comments are good and I wish I could participate in the discussion.
For example, perhaps some comments are right and I don't understand Cake. But if that is true, that tells me that Cake must be complex because I spent more time learning Cake than the other frameworks.
Wow. Thanks. I'm very glad to see the article being used. I see a lot of comments too on your post. I read them with Google Translate. A lot of the comments are good and I wish I could participate in the discussion.
For example, perhaps some comments are right and I don't understand Cake. But if that is true, that tells me that Cake must be complex because I spent more time learning Cake than the other frameworks.
че, инвайт ему выслать?
Cake не такой простой и не такой быстрый как остальные, но он позволяет, IMHO, кодировать проще. Вы потратите неделю на изучение, но за месяц напишите больше. И еще, попробуйте symfony.
Да, я в свободное от работы время ковыряю симфони. Уже вторую неделю (выходные, холодные зимние вечера). Мощный инструмент, который действительно позволяет сосредоточится на более специфических задачах. Да, требует хорошего понимания ООП, знания английского (а куда без него нынче) и выдержки — потому что дочитать книгу до конца порой трудно, не сорвавшись и не начать кодить какое-то приложение, но останавливаю себе тем, что если не дочитаю, то буду изобретать велосипед используя велосипед:)
Статья очень поверхностна, и мне кажется что выбраны фреймворки не очень высокого уровня (Cake не в счет). Сравнивать такие инструменты на хелло вордах — бессмысленно (выше уже сказали много по этому поводу), а то что фреймворк тяжел к пониманию и освоению не делает его плохим — «Тяжело в учении, легко в бою».
Статья очень поверхностна, и мне кажется что выбраны фреймворки не очень высокого уровня (Cake не в счет). Сравнивать такие инструменты на хелло вордах — бессмысленно (выше уже сказали много по этому поводу), а то что фреймворк тяжел к пониманию и освоению не делает его плохим — «Тяжело в учении, легко в бою».
Не могу пройти мимо)
Про проблемы с .htaccess — смешно. Не стоит браться за веб-разработку. не зная таких мелочей как mod_rewrite.
> Helpers, Actions, Behaviours, Layouts, Components… Неужели я должен знать обо всем этом чтобы написать мою программу?
Зачем все это для Hello World?
> В случае CakePHP оказалось очень тяжело обнаружить, какие же файлы оформления использовались.
Бугога)) В HTML-код не пробовали заглянуть?
> * URL возврата: вы переходите по ссылке, но сессия уже устарела. Вас перенаправляет на страницу авторизации. Вы логинитесь, и система авотматически возвращает вас на ту страницу, на которую вы пытались попасть. Как по мне, это очень удобно.
По моему это должно быть на любом сайте, обсуждать даже нечего.
> CodeIgniter и Yii поставляются с HTML-фильтрами, которые могут удалять JavaScript-код из пользовательского ввода.
Кривой путь решения, достаточно просто ознакомиться с функцией htmlspecialchars(), если вы используете php, или чуть подкрутить шаблонизатор, если вам лень все время писать эту функцию.
Про prepared statements уже известно лет 5 минимум, странно что в CI и Cake ничего похожего нет.
Вообще мне не нравится ни CakePHP (он генерирует слишком много запросов, там плохо реализованы модели), а CodeIgniter надо допиливать самому, например свой (или взятый откуда-нибудь) Database Access Layer, ну и много чего. С другой стороны. это все-таки бесплатные фреймворки, непрпавильно наверно требовать все готовое.
p.s. Код на темно-синем фоне, мелким и несглаженным (2009 год!!) шрифтом читается очень плохо, поверьте. Куда хуже, чем просто блок кода в
p.p.s. на Хабре обычно переводы оформляют как топик-перевод.
Про проблемы с .htaccess — смешно. Не стоит браться за веб-разработку. не зная таких мелочей как mod_rewrite.
> Helpers, Actions, Behaviours, Layouts, Components… Неужели я должен знать обо всем этом чтобы написать мою программу?
Зачем все это для Hello World?
> В случае CakePHP оказалось очень тяжело обнаружить, какие же файлы оформления использовались.
Бугога)) В HTML-код не пробовали заглянуть?
> * URL возврата: вы переходите по ссылке, но сессия уже устарела. Вас перенаправляет на страницу авторизации. Вы логинитесь, и система авотматически возвращает вас на ту страницу, на которую вы пытались попасть. Как по мне, это очень удобно.
По моему это должно быть на любом сайте, обсуждать даже нечего.
> CodeIgniter и Yii поставляются с HTML-фильтрами, которые могут удалять JavaScript-код из пользовательского ввода.
Кривой путь решения, достаточно просто ознакомиться с функцией htmlspecialchars(), если вы используете php, или чуть подкрутить шаблонизатор, если вам лень все время писать эту функцию.
Про prepared statements уже известно лет 5 минимум, странно что в CI и Cake ничего похожего нет.
Вообще мне не нравится ни CakePHP (он генерирует слишком много запросов, там плохо реализованы модели), а CodeIgniter надо допиливать самому, например свой (или взятый откуда-нибудь) Database Access Layer, ну и много чего. С другой стороны. это все-таки бесплатные фреймворки, непрпавильно наверно требовать все готовое.
p.s. Код на темно-синем фоне, мелким и несглаженным (2009 год!!) шрифтом читается очень плохо, поверьте. Куда хуже, чем просто блок кода в
p.p.s. на Хабре обычно переводы оформляют как топик-перевод.
«Я думаю, что отсутствие подготовленных выражений — это наиболее серъезная проблема CakePHP и CodeIgniter. „
мягко говоря это неправда в CI есть нормальный bindings
$sql = “SELECT * FROM some_table WHERE id =? AND status =? AND author = ?»;
$this->db->query($sql, array(3, 'live', 'Rick'));
в целом вообще автор не разобрался с защитой в CI
просто открываем изначальный конфиг для запуска application/config/config.php
CSRF — решается легко, не храните данные сессии в куках, база, включается в кофиге одной строкой, период хранения тоже есть, так же у сессий есть шифрация
// If you use the Encryption class or the Sessions class with encryption
// enabled you MUST set an encryption key. See the user guide for info.
$config['encryption_key'] = "";
всяческие XSS это так же в CI изначально не принимает get запросы, config.php есть строки сразу
$config['permitted_uri_chars'] = 'a-z 0-9~%.:_\-';
это принимаемы символы в URI
параметры если читать документацию забирать надо не через супер-переменные (хотя они при включенной $config['global_xss_filtering'] = TRUE; чистка идёт везде) а брать $this->input->post('bla-bla'); и смотреть вообще Input Class мануале, где описаны доп параметры и т.п. и что стоит по умолчанию
мягко говоря это неправда в CI есть нормальный bindings
$sql = “SELECT * FROM some_table WHERE id =? AND status =? AND author = ?»;
$this->db->query($sql, array(3, 'live', 'Rick'));
в целом вообще автор не разобрался с защитой в CI
просто открываем изначальный конфиг для запуска application/config/config.php
CSRF — решается легко, не храните данные сессии в куках, база, включается в кофиге одной строкой, период хранения тоже есть, так же у сессий есть шифрация
// If you use the Encryption class or the Sessions class with encryption
// enabled you MUST set an encryption key. See the user guide for info.
$config['encryption_key'] = "";
всяческие XSS это так же в CI изначально не принимает get запросы, config.php есть строки сразу
$config['permitted_uri_chars'] = 'a-z 0-9~%.:_\-';
это принимаемы символы в URI
параметры если читать документацию забирать надо не через супер-переменные (хотя они при включенной $config['global_xss_filtering'] = TRUE; чистка идёт везде) а брать $this->input->post('bla-bla'); и смотреть вообще Input Class мануале, где описаны доп параметры и т.п. и что стоит по умолчанию
Спасибо за материал. Есть вопросы по безопасности.
Про hmac не понял. Какая разница, что снифить?
Ну отправим мы вместо привычного 21232f297a57a5a743894a0e4a801fc3 (admin)
комбинацию 96b6bdeac4ec8c94053f0ce92e26c8e9 (тот же admin, но с привязкой к году по hash_hmac), что от этого изменится?
Каким образом время хранения кук влияет на их защищенность? Да пусть они хранятся хоть год, хоть секунду — пакет ушел на интересующий меня сайт, снифер это увидел. Решительно не понимаю.
И по поводу mysql_real_escape_string. Используйте Active Record. Любые параметры проходят через mysql_real_escape_string(). Мало? Ну добавьте в Active Record строчку preg_replace('/[^0-9A-Z]/iu', '', $param) против юникода, или укажите свой разрешенный диапазон символов через \x00-\xFF. В общем, не вижу проблемы c mysql_real_escape_string во фреймворках.
Про hmac не понял. Какая разница, что снифить?
Ну отправим мы вместо привычного 21232f297a57a5a743894a0e4a801fc3 (admin)
комбинацию 96b6bdeac4ec8c94053f0ce92e26c8e9 (тот же admin, но с привязкой к году по hash_hmac), что от этого изменится?
Каким образом время хранения кук влияет на их защищенность? Да пусть они хранятся хоть год, хоть секунду — пакет ушел на интересующий меня сайт, снифер это увидел. Решительно не понимаю.
И по поводу mysql_real_escape_string. Используйте Active Record. Любые параметры проходят через mysql_real_escape_string(). Мало? Ну добавьте в Active Record строчку preg_replace('/[^0-9A-Z]/iu', '', $param) против юникода, или укажите свой разрешенный диапазон символов через \x00-\xFF. В общем, не вижу проблемы c mysql_real_escape_string во фреймворках.
По поводу hmac: от сниффера, конечно, hmac не спасет, но мне думается, что он поможет от тупого брутфоса. В случае обычного md5, отсниференный хеш тут же суется в какой-нибудь md5decrypter.com — и с большой долей вероятности имеем наш пароль (или что там у нас было закодировано). В случае hmac — необходимо знать еще и секретный ключ.
Спасибо за своевременную статью — как раз собирался делать новый проект. В качестве альтернативы и для общего развития попробую сделать это на yii.
Ну что за идиотизм! Не являюсь фанатом CakePHP, однако:
1. Не было проблем с порогом вхождения, так как вначале прочел документацию.
2. После прочтения доков было понятно где что лежит и что заменять.
3. В CakePHP не требуется наличие базы и модели для контроллера — в доках написано, как отключить в своих экземплярах контроллеров.
4. График с АРС показывает более чем двухкратное превосходство YII — и это «тяжело утверждать об преимуществе в скорости».
Этих примеров хватило, чтобы поставить под сомнение ценность статьи для меня.
1. Не было проблем с порогом вхождения, так как вначале прочел документацию.
2. После прочтения доков было понятно где что лежит и что заменять.
3. В CakePHP не требуется наличие базы и модели для контроллера — в доках написано, как отключить в своих экземплярах контроллеров.
4. График с АРС показывает более чем двухкратное превосходство YII — и это «тяжело утверждать об преимуществе в скорости».
Этих примеров хватило, чтобы поставить под сомнение ценность статьи для меня.
На самом деле в кейке всё довольно легко и логично, а строгость позволяет легче работать в коллективе. Однако, на счёт ACL соглашусь, требует вникания :)
Не понял н4х нуженo ещё новое чудо ЯШШ | YII?
все существующие фрамеворки с недостатками!
если бы был хороший, то был бы только он один.
(думаю что Zend всех в61363т потихонечку)
все существующие фрамеворки с недостатками!
если бы был хороший, то был бы только он один.
(думаю что Zend всех в61363т потихонечку)
Сравнение производительности PHP-фремворков с изменением количества подключений к базе Тут. Как видим «Hello, world!» и реальные приложения — несколько разные вещи.
Для аутентификации и авторизации в Code Igniter можно использывать эту библиотеку
Хочу рассказать про свой опыт.
Необходимо было реализовать один проект. Но его особенность было то, что нет четкого ТЗ и четкого представления что должно быть и даже не было четких представлений о том какие связи между сущностями (один ко многим. многие ко многим). Был написан каркас на Yii + механизм распределения прав доступа по действиям с привязкой к ролям…
Но когда потребовалось создать механизм ногошагового заполнения данными 5-6 сущностей, котореы завязаны друг на друга — я с этими relations повесился…
Взял склет проекта на CI и переписал за двое суток аналогичнй функционал…
код игнитер 2.0 рулез )
Необходимо было реализовать один проект. Но его особенность было то, что нет четкого ТЗ и четкого представления что должно быть и даже не было четких представлений о том какие связи между сущностями (один ко многим. многие ко многим). Был написан каркас на Yii + механизм распределения прав доступа по действиям с привязкой к ролям…
Но когда потребовалось создать механизм ногошагового заполнения данными 5-6 сущностей, котореы завязаны друг на друга — я с этими relations повесился…
Взял склет проекта на CI и переписал за двое суток аналогичнй функционал…
код игнитер 2.0 рулез )
Хочу рассказать про свой опыт.
Необходимо было реализовать один проект. Но его особенность было то, что нет четкого ТЗ и четкого представления что должно быть и даже не было четких представлений о том какие связи между сущностями (один ко многим. многие ко многим). Был написан каркас на Yii + механизм распределения прав доступа по действиям с привязкой к ролям…
Но когда потребовалось создать механизм ногошагового заполнения данными 5-6 сущностей, котореы завязаны друг на друга — я с этими relations повесился…
Взял склет проекта на CI и переписал за двое суток аналогичнй функционал…
код игнитер 2.0 рулез )
Необходимо было реализовать один проект. Но его особенность было то, что нет четкого ТЗ и четкого представления что должно быть и даже не было четких представлений о том какие связи между сущностями (один ко многим. многие ко многим). Был написан каркас на Yii + механизм распределения прав доступа по действиям с привязкой к ролям…
Но когда потребовалось создать механизм ногошагового заполнения данными 5-6 сущностей, котореы завязаны друг на друга — я с этими relations повесился…
Взял склет проекта на CI и переписал за двое суток аналогичнй функционал…
код игнитер 2.0 рулез )
Что вы не совсем проникли в CakePHP, или может документация стала лучше, во многом в его сторону не согласен с вами. Особых сложностей что избавиться (впервые!) со стандартной темой не было, что несколько отображений из контроллера одна строчка render(); что других проблем, на мой взгляд сильные соглашения в кэйке способствуют что следующий разработчик увидев код и зная эти соглашения быстрее поймет его и сделает также для другого, а не как хочет, а потом сиди копай что тут программист хотел и что с чем связано.
В общем я не жалуюсь на CakePHP. Заинтересовался и собственно узнал о нем на собеседовании где с Code Igniter собрались переписывать на Yii. Тем самым стоит предположить что Code Igniter хуже Yii, первым фактором сослались на производительность.
В общем я не жалуюсь на CakePHP. Заинтересовался и собственно узнал о нем на собеседовании где с Code Igniter собрались переписывать на Yii. Тем самым стоит предположить что Code Igniter хуже Yii, первым фактором сослались на производительность.
Для меня CI оказался самым простым, лёгким и понятным)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Сравнение PHP-фреймворков: CakePHP, CodeIgniter и Yii