Пользователь
0,0
рейтинг
30 января 2009 в 02:30

Разработка → Сравнение PHP-фреймворков: CakePHP, CodeIgniter и Yii

PHP*
Не так давно на Хабре проскакивал пост о появлении нового PHP-фреймворка под названием Yii.
После ознакомления, этот фреймворк показался мне интересным, перспективным и достойным внимания.
Недавно Daniel Carrera выложил в своем блоге интересную статью «Comparison of PHP frameworks» о сравнении CakePHP, CodeIgniter и Yii.
С целью популяризации Yii среди русскоговорящего (и плохо-по-английски-читающего) населения я решил сделать перевод.

Осторожно: букв действительно много.
Содержание

  • Простота
  • Документация
  • Производительность
  • Гибкость
  • Безопасность
  • Другие замечания
  • Итоги


Простота


Тяжело судить о простоте фреймворка до создания приложения, но я могу привести несколько комментариев, основываясь на документации:

CakePHP

Установка: У меня возникли проблемы с Apache, которые не были документированы. Мне пришлось редактировать три файла .htaccess, чтобы добавить команды «RewriteBase».

Использование: Helpers, Actions, Behaviours, Layouts, Components… Неужели я должен знать обо всем этом чтобы написать мою программу? Похоже, у Cake
наивысший порог вхождения и на текущий момент я не вижу у него никаких особых возможностей, которые бы не предоставляли остальные фреймворки.

Все фреймворки поставляются с дефолтным оформлением и CSS. В целях тестирования мне пришлось избавляться от этого, чтобы каждый фреймворк делал только то, что требуется. В случае CakePHP оказалось очень тяжело обнаружить, какие же файлы оформления использовались. Это было нелогичное место (внутри моей директории приложения).

CodeIgniter

Установка: Тривиальная. Всего лишь распаковать файлы и все готово к работе.

Использование: CodeIgniter кажется достаточно простым. Документация не дает повода усомниться в этом. Мое приложение «hello-world» было готово намного быстрее, чем при использовании Cake. В общем, порог вхождения у CI ниже.

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

Yii

Установка: Легкая. Необходимо запустить yiic, чтобы создать корневую веб-директорию. Имеется также PHP-версия (yiic.php), которая хороша, если у вас нет ssh-доступа. Yiic хорошо документирован.

Использование: Yii также кажется простым и понятным, разве что чуть меньше, чем CodeIgniter. Мой «hello-world» был создан почти так же быстро, как и в случае с CI.

Все фреймворки поставляются с дефолтным оформлением и CSS. В целях тестирования мне пришлось избавляться от этого, чтобы каждый фреймворк делал только то, что требуется. С Yii это было очень просто. Файл оформления находится в логичном месте и это хорошо документировано.

Я счастлив сообщить, что ни один из фреймворков не требует изучения языка шаблонизатора, типа Smarty. PHP сам по себе является отличным шаблонизатором. Я использовал Smarty несколько лет и, честно говоря, считаю, что от него больше проблем, чем пользы. Замечу, что Yii и CodeIgniter поставляются с
опциональным шаблонизатором, специально для тех, кому это нравится. Но, как я уже сказал, это опционально.

Результат: CodeIgniter кажется наиболее простым, за ним очень близко следует Yii.
Я отложу окончательный вердикт до момента, пока не напишу прототипы приложений во второй части тестирования.

Документация


Пожалуйста, отнеситесь к сказанному критически. Документация обычно начинает выглядеть немного по-другому, когда вы в действительности пишете приложение. Если она неточна или неполна, вы не узнаете об этом до момента начала работы. До сих пор единственным приложением, написанным мной под тестируемые фреймворки, является «hello world».

CakePHP

Мое первое впечатление было положительным. Документация выглядит полной и легкочитаемой. Туториалы было достаточно тяжело обнаружить (они оказались в разделе «Example Applications»). Когда я написал свой «hello world», я столкнулся с проблемой (404 error) и это не было описано в документации. Мне пришлось подредактировать файлы .htacces, чтобы решить это. Я бы хотел видеть раздел «Устранение неполадок» в документации. Кроме того мне было очень тяжело выяснить, как избавиться от примочек (хедер, футер, стили), которые присутствуют в Cake по умолчанию.

CodeIgniter

Первое впечатление было снова позитивным. Замечу, что написание «hello world» заняло у меня намного меньше времени, чем в случае с Cake. Я думаю, причина в том, что CI проще, но также считаю, что на это повлияла и документация.

Yii

И снова мое первое впечатление оказалось положительным, я написал «hello world» очень быстро. После этого я избавился от дополнительных примочек, которые Yii подключает, чтобы сделать страничку симпатичной. Найти как это сделать было очень легко и быстро.

Результат: На данный момент тяжело судить.
Похоже, что у всех фреймворков хорошая документация. У меня было пару проблем с Cake, но я пока что не могу ничего заявить твердо.

Производительность


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

Основные сходства:
Оба теста пытаются оценить минимальные накладные расходы каждого фреймворка. Задача фреймворка — вывести «Hello World» и больше ничего.

Основные различия:
Я использовал конфигурацию каждого фреймворка по умолчанию. Команда Yii піталась оптимизировать каждый фреймворк, чтобы отобразить «Hello World» максимально быстро.
Тест от Yii выполняет только die(). Мой же использует MVC: контроллер устанавливает значение переменной в «Hello World», затем она передается представлению для вывода на основной HTML-странице.
Yii использовали выделенный сервер для тестов, а я — shared hosting, где собираюсь размещать мое реальное приложение.

Таким образом, тесты команды Yii более технически честны, но мои лучше отображают поведение в реальном мире.
Как всегда, все тесты следует воспринимать критически.
Результаты выражены в запросах в секунду (Requests Per Second, RPS), поэтому большие значения — лучше.
image

Детали тестирования:
Данная страница на сайте Yii описывает их тест. В моем тесте каждый фреймворк содержал следующий код в представлении:
image

Где переменная $message предоставляется контроллером, а ее значение — «Hello World». Количество запросов в секунду выяснялось при помощи утилиты ApacheBench с такими параметрами: «ab -t 30 -c 10 URL». Моя тестовая среда — это shared hosting со следующими параметрами:

* CentOS 4 Enterprise Linux.
* Apache 2
* PHP 5.2.6
* CPU: Quad-Core AMD Opteron(tm) Processor 2350
* Memory: 8GB

Выводы: Yii и CI оба выделились в плане скорости. Возможно Yii и имеет некоторое преимущество, но однозначно утверждать тяжело.

Гибкость


CakePHP

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

CodeIgniter и Yii

CodeIgniter и Yii оба выглядят достаточно гибкими. Посмотрев в документацию, проблематично будет сказать, что один точно более гибкий, чем другой.
Оба используют шаблон MVC, но не кажутся очень строгими в этом плане. CakePHP намного больше зависит от соглашений, чем Yii и CI.

Некоторые примеры сходств и различий:
* Каждый из фреймворков ожидает от вас следования соглашениям об именовании контроллеров.
* CakePHP требует создания модели, базы данных и таблицы, даже если они не используются в вашей программе.
* Cake сам вызывает представление автоматически, основываясь на имени контроллера. В CI и Yii вы вызываете представление явно, поэтому у Cake соглашения более преобладают над конфигурацией. В свою очередь, в CI и Yii вы можете вызывать несколько представлений.

Вот пример кода:
image

Как можно видеть, версии для CI и Yii не кажутся более сложными, чем для CakePHP, кроме того у них есть дополнительная возможность — вы можете загружать более одного файла представления. К примеру, вы можете загрузить специальный хедер, вставить виджет и т.п.

Результат: CodeIgniter и Yii оба выглядят более гибкими. На данным момент я не могу определить, какой из них более гибкий.

Безопасность


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

Контроль доступа

Предварительная информация тут — Аутентификация и Авторизация.

CakePHP

Я обнаружил, что система контроля доступа в CakePHP трудна для понимания. Для генерации файлов схем и списков контроля доступа (ACLs) используется генератор кода («cake bake») — этот процесс выглядит замысловато. Некоторые термины (ACOs, AROs, Requester) добили меня окончательно.

Я ожидал, что контроль доступа — это непросто, но в Cake это оказалось намного более сложным, чем я предполагал. Выглядит достаточно мощно, но тяжело в использовании. Я почувствовал, что не контролирую процесс и не понимаю, что же происходит. А безопасность — это именно то, над чем бы я хотел иметь контроль и что я бы хотел хорошо понимать.

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

CodeIgniter

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

Yii

Я намного быстрее понял систему контроля доступа в Yii. Я бы не сказал, что она проста, но это потому, что контроль доступа сам по себе непрост. Я бы сказал, что в Yii система контроля доступа проста настолько, насколько это возможно — но не более того. После того как я прочитал документацию, мне показалось, что я понимаю процесс и что я способен изменить его под мои нужды.

Быстрый тест: я смог тут же найти, как усилить стойкость паролей.

Некоторые фишки Yii, которые мне нравятся

* Гибкость: у вас могут быть правила доступа, основанные на пользовательском IP-адресе или типе запроса (GET vs POST), или правила для анонимных и авторизированнх пользователей.

* URL возврата: вы переходите по ссылке, но сессия уже устарела. Вас перенаправляет на страницу авторизации. Вы логинитесь, и система авотматически возвращает вас на ту страницу, на которую вы пытались попасть. Как по мне, это очень удобно.

* Контроль доступа, основанный на ролях (Role Based Access Control): RBAC более гибкий и мощный способ, нежели традиционные ACL. С фреймворком Yii вы можете писать свое приложение, не обращая внимания на RBAC, и использовать его только в тех случаях, когда требуется решить специфическую задачу. Итак, система настолько гибкая, насколько должна быть, но ваши правила доступа сложны не более, чем того требуется.

Атаки по словарю (Dictionary attacks)

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

Есть множество методов прерывания атаки по словарю: блокировка аккаунта после Х неудачных попыток авторизации, временные задержки, CAPTCHAs. Каждый их них имеет свои преимущества и недостатки. Блокировка аккаунтов — это легко и эффективно, но дает возможность для атаки на отказ в обслуживании: кто-то может совершить множество попыток авторизации, но не для того, чтобы получить доступ, а чтобы вызвать блокировку других пользователей. Вот один их методов, которые мне нравятся: после 5 неудачных попыток вы должны решить капчу, чтобы получить дополнительные попытки. Это позволяет контролировать атаки по словарю, DoS и удобство для пользователя.

Ни один из фреймворков не имеет средств, относящихся к проблемам атак по словарю или отказа в обслуживании, но я этого и не ждал. Настоящий вопрос в том, сможете ли вы в данном фреймворке настроить способ авторизации именно так, как нужно вам? Это вопрос контроля и гибкости. В CI и Yii я уверен, что смогу это сделать. Однако я не так уж уверен в этом в случае CakePHP.

Межсайтовый скриптинг (Cross-site scripting attacks, XSS)

XSS опережает переполнение буффера в рейтинге наиболее распространенных проблем безопасности. Это работает так: Кто-то публикует комментарий в вашем блоге и это сообщение включает в себя вредоносный JavaScript-код. Когда вы просматриваете блог, код исполняется. Так как код берется из вашего домена, он считается браузером «безопасным». Этот код может читать ваши кукисы, или изменять содержимое страницы (например, «Сессия истекла. Пожалуйста введите ваш пароль.»).

CodeIgniter и Yii поставляются с HTML-фильтрами, которые могут удалять JavaScript-код из пользовательского ввода. К сожалению, CakePHP не имеет таких фильтров.

Внедрение SQL-кода (SQL injection attacks)

Внедрение SQL-кода является одной из наиболее частых атак и брешей в безопасности веб-приложений (комикс). Это происходит, когда текст, введенный пользователем, интерпретируется как исполняемый SQL-код. Например:
image

Предположим, пользователь ввел пароль foo' OR 1='1. Тогда запрос будет таким:

image

Так как 1='1' — всегда истина, запрос вернет список всех пользователей. Наиболее частое (и неверное) решение — экранирование строк при помощи функций типа addslashes() или mysql_real_escape_string():

image

Что же не так с этим решением?
* Оно подвержено ошибкам, так как вы должны не забыть это сделать для каждого параметра.
* Также оно зависит от того, что кто-то может найти все возможные символы, которые могут использованы для взлома. Хорошие ребята находят все дырки, плохим же достаточно найти одну. Это игра для лузеров.

Chris Shiflett показывает, как провести внедрение SQL-кода в обход addslashes, используя китайский символ. Откуда мы можем знать, что не найдется какой-нибудь тамильский символ, который позволит обойти mysql_real_escape_string?

Правильное решение: подготовленные выражения (prepared statements)

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

Поддерживает ли фреймворк подготовленные выражения?

К сожалению, лишь один из трех фреймворков — Yii — предоставляет такую возможность. Я думаю, что отсутствие подготовленных выражений — это наиболее серъезная проблема CakePHP и CodeIgniter.

Подделка межсайтовых запросов (Cross-site request forgery attacks, CSRF)

Подделка межсайтовых запросов (CSRF) используется в некотором смысле дополнительно к атакам с помощью межсайтового скриптинга(XSS). XSS злоупотребляет доверием клиента серверу, CSRF — доверием сервера клиенту. Представьте, что Боб посещает вредоносный сайт, содержайщий следующий тэг image:
image

Если Боб в данный момент авторизирован на своей банковской странице, то сервер банка получит запрос от Боба о переводе $10,000 на счет Евы.

Что же можно сделать для защиты от CSRF? Кроме того, что можно уменьшить период жизни кукисов, основным решением служит использование секретного значения для аутентификации любых параметров GET и POST, которые могут изменять данные на сервере.

CakePHP и CodeIgniter, похоже, не имеют средств для борьбы с CSRF. Yii предлагает защиту от CSRF для POST-запросов путем использования секретных токенов (вы должны включить эту функцию). Чтобы польностью защититься от CSRF вы должны быть уверены, что GET-запросы не могут изменять данные на сервере.

Кража куки (Cookie hijacking attacks)

Куки обычно используются для хранения достаточно значимой информации, такой как идентификаторы сессий, имена пользователей, хеши паролей. Кража куки — это когда третье лицо получает доступ к вашим куки. Это возможно сделать, используя XSS или пакетный сниффер.

Как защититься от кражи куки? SSL защитит вас от снифферов, и вы должны принять меры для предотвращения XSS-атак. Вы можете сделать куки менее значимыми, отказавшись от длительного хранения в них значимой информации. Например, вместо хранения md5(passwd) используйте хеши, срок дествия которых истекает — HMAC(date,md5(passwd)).

Насколько я знаю, CakePHP и CI не обладают никакими защитными механизмами против краж куки. Yii имеет возможность проверки куки, которая использует HMAC для аутентификации содержащихся данных. Атакующий не сможет изменить данные истекшего куки (например, дату истечения), не будучи замеченным.

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

Победитель: Yii
Yii имеет значительное преимущество в плане безопасности, с лучшей системой контроля доступа и защитой от XSS, внедрения SQL-кода, подделки межсайтовых запросов и краж куки.
CakePHP и CodeIgniter немного разочаровывают в этом плане. Так как CI более гибкий, в нем будет легче добавить требуемые средства защиты самому.

Другие замечания


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

Prototype
CakePHP использует библиотеку Prototype. Я имел дело с Prototype. В основном, она загрязнет глобальное пространство имен и может поломать уже работающий JavaScript-код. Таким образом, Prototype не ведет себя хорошо с вашим кодом или другими библиотеками.

Запланированные релизы
У Yii имеются запланированные релизы. Я бы хотел, чтобы так было у всех opensource-проектов.

Фильтрация ввода
У CodeIgniter есть отличный класс Input, который производит очистку данных. Он уничтожает массив GET и все глобальные переменные, кроме POST и COOKIE. Эта фишка не совсем вписывается в мои критерии, но способствует более хорошему коду, и поэтому достойна упоминания. О XSS-фильтрации я упоминал в предыдущем разделе.

Итоги


Мое мнение — CakePHP несомненно хуже, чем CI и Yii. Документация, в общем-то, хороша, но не лучше, чем у CI и Yii. Я не вижу ни одной области, в которой Cake выглядит отчетливо лучше CI или Yii. Он может быть лучше для простых приложений, которые делают все именно так, как того ожидает Cake. Но в общем, Cake более сложен, нежели CI or Yii, и похоже что оно того не стоит.

Yii и CodeIgniter очень близки. Они практически равны по производительности, документации и гибкости — оба быстры, хорошо документированы и достаточно гибки. CodeIgniter кое в чем проще, но у Yii преимущество в безопасности. Я дождусь момента, пока не напишу прототипы приложений на каждом из них, чтобы сформировать окончательное мнение.

Обычно я не люблю сравнительные таблицы, так как они слишком упрощают вещи. Но я понимаю, что люди часто хотят видеть краткую итоговую таблицу, поэтому предоставлю примерный набросок:

image

[1] Воспринимайте критично. Тяжело судить о документации до того, как приступишь к написанию программы.
[2] CodeIgniter получает очко за фильтрацию XSS и общую гибкость.

Оригинал статьи и копирайты — Daniel Carrera, «Comparison of PHP frameworks — Part I»
Евгений Халецкий @xZenon
карма
103,0
рейтинг 0,0
Пользователь
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (136)

  • 0
    (В PHP не смог разместить из-за отстутствия кармы)
    • +2
      Ну вот вам +
      • 0
        Спасибо вам и всем, кто проплюсовал. Успешно перенес в блог PHP.
    • 0
      поддержу, уже 10.00
    • +7
      «Helpers, Actions, Behaviours, Layouts, Components… Неужели я должен знать обо всем этом чтобы написать мою программу?»

      ага — вам еще не надо знать основы ООП, жизенного цикла и основы проектирование приложений. вот отсюда и идут прогерры кто на коленке все пишет лапшой.
      • 0
        Автор, собственно, хотел написать всего лишь «hello world».
        • +2
          для это framework не нужен :)
          • 0
            Но начинать с чего-то нужно. Кроме того, насколько я понял из статьи, автор и собирается реализовать некое относительно серъезное приложение на каждом их фреймворков.

            В оригинале, на странице блога автора есть такое:
            Part II will be the result of my experience as I use each framework to write a prototype for my real-world application.
            • +1
              вот после написания апликухи и надо было писать эту статью. вполне может оказаться что то, что не прошло с hello world, может отлично быть с реальной апликухой.

              Все равно что: «блин БМВ не сразу завел, так я на ЗАЗе гонки выиграю, там всего-то два проводка сомкнуть.»
      • 0
        страшно подумать, что бы он написал про ZF
        • 0
          )))) Очень любил первый ZF (второй конечно, разочаровал), но да, лэйауты, хелперы, экшены, роуты ) и полное отсутствие модели и какого-бы то ни было best practice.
  • 0
    интересно, чем обосновывается выбор фремворков для сравнения?
    Я не в плане. что критикую, на самом деле интересно.
    За статЬю спасибо — очень познавательно.
    • –1
      CakePHP один из самых первых фреймворков, CI && Yii имеют общего автора.
      • +3
        CodeIgniter разработан компанией EllisLab, а также Риком Эллисом (Rick Ellis) и Полом Бурдиком (Paul Burdick). Yii Framework же разработан китайцем Qiang Xue.
        • +1
          к слову заметить что это китаец кторый живет в калифорини еще являтся автором замечательного фреймворка — клона ASP.NET — Prado, дядя он толковый и Yii получился на славу. Но канечно блогер что сравнвавший фреймвокри действительно не хотел вдавться в Cake, он просто сделал выбор и решил в письменной форме его утвердить для себя самого.
          • 0
            Гм, точно. Спасибо, я перепутал Prado с CI.
    • +1
      я бы для сравнение еще Zend Framework добавил
      • 0
        На сайте Yii Framework есть сравнения производительности не только с Zend и подобными :)
        • 0
          Только это все приложения «hello word». А в случае таких приложений мы можем сравнивать только уровень накладных расходов на старт приложения. Поскольку функционал больше ни для чего другого не используется.
          • 0
            А какой энтузиаст вообще будет сравнивать полностью функционал? У кого есть столько времени?

            Всё равно, даже сравнение накладных расходов по дефолту учитывать нужно(например для маленьких проектов). Естественно ненужный функционал можно выкинуть, но когда горят сроки…
  • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      Если не ошибаюсь, в Yii по дефалту стоит output caching.

      В controller'e CodeIgniter, в конструкторе поставь следующее:

      $this->output->cache(60);

      Уверен, результат будет иным.
  • +8
    >* CakePHP требует создания модели, базы данных и таблицы, даже если они не используются в вашей программе.

    Неверно, не требует, а предполагает, при необходимости модели и таблицы можно и не создавать. Насчет БД вообще не уверен

    >* Cake сам вызывает представление автоматически, основываясь на имени контроллера. В CI и Yii вы вызываете представление явно, поэтому у Cake соглашения более преобладают над конфигурацией. В свою очередь, в CI и Yii вы можете вызывать несколько представлений.

    В Кейке никто не запрещает отменить вывод представления, или рендерить конкретное, а также несколько

    >Оба используют шаблон MVC, но не кажутся очень строгими в этом плане. CakePHP намного больше зависит от соглашений, чем Yii и CI.

    Для кого-то строгость недостаток, для кого-то преимущество. А вообще заметил такую особенность при изучении CI и CakePHP после «трупхп» (не то что MVC, а даже простого отделения бизнес-логики нет, не взирая на использование шаблонизаторов) — те, кто сначала разберется с кейком (а порог вхождения у него действительно выше), потом пишут понятный код на CI, а вот если наоборот, то в коде CI бывает очень сложно разобраться. Ладно с моделями, когда модель выполняет только функцию обертки для БД, а в контроллерах, например, вычисляется FirstName+' '+LastName, но вот когда начинают (а начинают часто)в контроллерах собирать виды из «кусочков» (открывающий тег html в одном файле, закрывающий в другом) то сложновато поддерживать такой код
    • +2
      добавлю от себя:
      >Использование: Helpers, Actions, Behaviours, Layouts, Components… Неужели я должен знать обо всем этом чтобы написать мою программу?
      а чего хотели то? фреймворк или либу? Если писать хеловорды, то конечно ниче учить не надо.

      >я столкнулся с проблемой (404 error) и это не было описано в документации. Мне пришлось подредактировать файлы .htacces, чтобы решить это.
      автор — слепой, ибо это описано

      >В случае CakePHP оказалось очень тяжело обнаружить, какие же файлы оформления использовались.
      действительно, не прочитав документацию… очень сложно понять, что надо поменять /views/loayouts/default.ctp

      >Результат: CodeIgniter и Yii оба выглядят более гибкими. На данным момент я не могу определить, какой из них более гибкий.
      автор, читайте доки… кейк расширяем по самое не могу

      >Быстрый тест: я не заметил явного пути, как усилить стойкость паролей. В туториале сказано, что если вы будете хешировать пароли самостоятельно, то приложение не будет работать.
      автор, курите доки… Auth Component делает засоленные пароли на основе самой стойкой хеш функции, которая есть у вас в пхп + соль берется из Security.salt, котрая указывается в в конфиге. мало того, если надо, можно отнаследоваться от стандартного компонента и реализовать свою функцию хеширования, пароливания:)

      вывод:автор — мудакне читает доки, просто не хотел даже разбираться
      • –10
        А как Вас на хабр пустили? или всем приятно читать откровенный бред?
        • –12
          это как тебя сюда пустили, если уж на то пошло:
          • –1
            для тех, кто не понял — автор не написал тут _ничего_ полезного, при этом позволяет себе судить о том, кому быть тут, а кому нет
            • 0
              Не соглашусь, я уже знаю основной для меня недостаток Yii :)
              • –1
                эм… я имел в виду автора комментария:)
                PS какой же?
                • 0
                  Торможу… тяпница… пиво… :)

                  Он предполагает прямой вызов вида из контроллера и очевидно допускает (об этом сказано в статье напрямую) сборку в контроллере html кода из нескольких шаблонов, то есть реализацию логики представления на уровне логики приложения. Имхо, это не способствует написанию «хорошего» кода.
                  • –2
                    ну… в каке тоже можно такое делать, если захотеть, но соглашусь
                    • 0
                      Можно, но как раз для этого нужно «рыться» в документации :) Я не один раз видел разницу между кодом, написанным человеком, который сначала осваивал CI (а судя по статье он очень схож с Yii в этом отношении), а потом Cake и наоборот. Если сначала человек изучал кейк, а потом Ci/Kohana, то он в них старается эмулировать layout. А если CI сначала (особенно если PHP первый язык и о «всяких» MVC представления нет), то начинает собирать из «хидеров/футеров» и в нем.

                      Может любители CI/Kohana/Yii со мной не согласятся, но, имхо, в среде PHP-фреймворков CI и его потомки занимают тоже место, что и сам PHP среди других языков для сервер-сайд веб-разработки. Низкий порог вхождения, но провоцирует появление «быдлокодеров» — бесконтрольная свобода часто превращается в анархию :)
    • 0
      из своего опыта:
      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.
      нужен некий прирост производительности: убирается ненужное. на свой страх и риск.

      опять же — каждый проект имеет свои нужды
      • 0
        совет: HtmlHelper::link() использует много ресурсов, если его заменить на обычные ссылки — почувствуете некую разницю во времени. (при условии если в view много $html->link )

        взято из
        codesith.blogspot.com/2007/09/cakephp-performance-tuning.html
        groups.google.com/group/cake-php/browse_thread/thread/1eab831f222d195a
        • 0
          тоже думаю, что в продакшн версии нужно много конструкций $html->method() и $form->method() позаменять на их html output.
          дествительно, если в форме 10 инпут-текст-полей, зачем 10 раз дергать метод $form->text(some_field_d, ....)
          если взять да и заменить на
          <input type=«text» name=«date[Model][SomeFieldN]» ....>
          • +1
            не-не-не, дэвид блейн. их не затем писали, чтобы вы заменяли их на что-то другое. $html->link автоматически поддерживает reverse routing и в зависимости от прописанных маршрутов сам создаст нужную ссылку. а $form поддерживает подписывание форм компонентом Security, а также занимается всякими другими полезными вещами типа вывода сообщений валидатора. но если это все не нужно, то можно конечно =)
            • 0
              не, я же говорю про $form->text() а не про $form->input(). Последний конечно же занимается и сообщениями валидатора и сотворением лейблов.
              а вместо $html->link() писать заведомо ведомый с уже известными в продакшене роутами.
              Естественно не поголовно все менять, а только ту часть которая будет всегда статической :)
              Но это конечно, если руки дойдут…
              • 0
                *писать заведомо ведомый < a href="" >

                (парсер съел теги)
            • 0
              если делать $html->link('qwe', '/foo/bar') — ест меньше, насколько я помню
    • +1
      поддерживаю
      автор протестировал очень поверхностно, основываясь на собственных придуманных и непонятных тест-кейсах. Кому нужно тестировать hello world? Да, кейк медленне, но напиши-те ка каркас социальной сети, у которой в бд будут присутствовать множество связанных таблиц, и повыгребать это нс CI или Yii, и вы хорошенько подолабетесь по выгребанию этих «гребанных»(пардон) связанных записей. Кейк с этим справляется, а код — довольно понятный. Даже не то что довольно понятный, а совсем понятный, можно хорошо проследить логику. Даст автору CI такие возможности?
      Топик следовало назвать «Сравнение производительности фреймворков на приложении „hello world!“»

      • 0
        о, как у вас с производительностю?
        сколько таблиц в БД?
        • 0
          таблиц пока 50, и конечно же, производительность хромает
          поэтому активно использую кэширование (для выборок с разными contain() — разные кэши). очень классная вещь :)
      • 0
        Имхо на серьезных нагрузках и сложных структурах проще будет на чистый SQL перейти, чем потом разбираться, что там ORM намудрил с запросами и почему все тормозит безбожно.
  • +9
    шо опять?
    сто тысяч миллионов раз уже обсуждалось почему сравнение фреймворков не имеет смысла на уровне приложений уровня хелловорлд.
    codeigniter не использую, поэтому сказать ничего не могу, но в cakephp вы не разбираетесь совсем и документацию даже не читали. зачем например вам понадобился RewriteBase? защита от кражи куки обеспечивается в компоненте Session, а csrf — в Security. и тд и тп.
    стыдно, товарищ.
    • +1
      В CI тоже куки защищаются в сессиях
    • +2
      «сто тысяч миллионов раз уже обсуждалось почему сравнение фреймворков не имеет смысла на уровне приложений уровня хелловорлд.»
      Проблема в том чтобы найти человека, у которого хватит времени и сил на то, чтобы хорошо разобраться в существующем многообразии фреймворков. Вы можете дать ссылку на статью от такого человека? Я бы с удовольствием ее прочитал(можно и на английском).

      Кстати, вы заметили что это перевод? =)

      • +1
        не разбираешься — не пиши, что я тут могу сказать. а вообще если это перевод, то можно любую ахинею переводить что ли?
        • 0
          Дык а вседаки вы можете дать ссылку на правильную, по вашему, статью о сравнение фреймворков? Если нет, то уж лучше это, чем совсем ничего. Как иначе узнать, что лучше то(понятно, что нужно пробовать самому, но это довольно сложно и на мой взгляд не очень осуществимо)?

          «а вообще если это перевод, то можно любую ахинею переводить что ли?»
          Нет, но не стоит ведь путать автора и переводчика. И про перевод я написал главным образом потому, что для меня является удивительным как можно прочитать статью и не заметить, что она лишь переведена, а не написана =)
          • 0
            У меня есть идея написать некое реальное приложение на нескольких фреймворках, потихоньку ее реализую, было бы уже почти готово (хотел сравнивать только 4 PHP фреймворка, но открыл для себя руби и питон, надо освоить рельсы и джанго, жду очередных капель и унций :) ). Другое дело, что любое сравнение будет некорректно в конкретных условиях. Знаю, например, что многие не реализуют в CI/Kohana паттерн декоратора (layout в кейке, симфони, руби...), а собирают вид по частям из хидеров/футеров. Я так писать не буду, но наверняка кто-то придерется
            • 0
              А еще есть Java :) Если действительно будете писать статью с охватом php, python и ruby, то добавьте сайт ostov.org (там сейчас нет ничего) в закладки. Я сейчас разрабатываю фреймворк на основе Tapestry5, Hibernate и еще множестве других подфреймворков. И помогу вам с этой статьёй, всё что касается Java и Ostov :)
  • +14
    человек просто не хотел разбираться нормально в cake.
    • –6
      Может в кейке он и не разобрался, но CI лучше:)
      • 0
        ну не надо холиварить… нравиться — пишите. А вообще каждый фреймворк — под определенную задачу.
        • –4
          Оо еще один защитник своей конфетки, ну нравится так и пишите, что любите Cake.

          А насчет «каждый фреймворк — под определенную задачу» — мягко говоря это не совсем так.
          • +3
            я не защитник. Я противник холиваров. А на сами фреймворки мне посрать — мы пишем так вообще на своём.
          • 0
            ошибаетесь.
            вот, например, для helloworld вообще по сути не нужен никакой фреймворк
            нет ничего универсального

            • +1
              Согласен, но как это связано с тем что я выше написал.
              Я бы все фрэймворки PHP разделил на 3 группы
              1) Комбайны, которые все могут и для них миллион дополнений: ZEND
              2) Популярные, которые много могут: CI, Cake, и еще несколько
              3) И так мелкие, малоизвестные, бажные: основная масса PHP фрэймворков.

              Ну так вот мы либо пишем на чистом PHP, Либо если хотим использовать что-то сложное, большое и знаем что это есть в зенде — используем зенд.
              Если не боимся фрэймворков, то любой сайт(web-приложение) можно писать на любом фрэймвоке из второй группы, и здесь абсолютно по барабану на каком именно из них(в об этом то я и писал комментарием выше).
              А третья группа просто просто для неопытных программистов, либо для тех кто и писал эти недофрэймворки. Со временем, развиваясь, конечно, экземпляры третьей группы могут попасть во вторую.
    • +1
      Значит еще один минус в сторону cake, так как старт на нем будет намного медленнее чем на других фреймворках при сравнении приложений хелловорлд, а если уже говорить о полноценном сравнении то читаем habrahabr.ru/blogs/php/50341/#comment_1331982
      • 0
        Вы писали на cake что-нить сложнее хелловорлд? Если нет — то я думаю, что ваши суждения и выеденного яйца не стоят. по мне так для хелловорлд самый быстрый старт — пуре ХТМЛ.
  • 0
    Я не знаю что Вы имели ввиду, но может сначала надо было бы разобраться в CakePHP.
    И вообще. как можно о(б)суждать тО, чего не знаете?
    Извините, но то что Вы написали про CakePHP — это бред!
    • +3
      Справедливости ради — вообще-то это перевод, о чем сказано и в первых строках поста, и в последних :)
      • +9
        ну пусть переведет наши комментарии обратно
        • 0
          ага, горе-Даниеля на мыло
    • +2
      Хочу заметить, что это всего лишь перевод статьи Daniel Carrera.
      На мой вгляд, статья писалась не с задачей развить новый холивар, а просто показать миру новый фреймворк.

      Да, возможно автор оригинала и преувеличил некоторые моменты и не разобрался во всех тонкостях CI и CakePHP. Тут уже судить более опытным адептам религий CakePHP && CI.

      Тем не менее, думаю Yii Framework имеет право на существование и своё достойное место.
    • +1
      Поддерживаю мнение, высказанное bethrezen ниже — статья просто предлагает ознакомиться с Yii, как новым фреймворком, показав, что в нем уже имеется на данный момент.
      Естественно, ничего не утверждается окончательно и бесповоротно — автор и сам говорит, что не писал ничего серъезного ни на одном из указанных фреймворков.

      Просто Yii — очень свеженький фреймворк, и и информации по нему пока почти нет, а тем более на русском языке. Я поэтому и решил перевести статью — у людей будет больше информации и возможности с ним ознакомиться -> больше людей попробуют/выскажут мнение/доработают код. В итоге получим более качественный и функциональный фреймворк, с большим комьюнити =)
      • 0
        … высказанное bethrezen *выше*…
        • 0
          Буквально несколько часов назад qiang поблагодарил всех добровольцев, согласившихся переводить документацию. Она будет доступна с версии 1.0.2, запланированную на 1 февраля.

          Комьюнити совсем скоро уже сделает свой первый осознанный и крепкий вдох :)
          Думаю дифицита различной объективной информации уже не будет.
  • +8
    а что Зенд Ф. уже не считается одним из самых популярных фреймуорков, я бы с большим удовольствием почитал именно о нём.
    • 0
      В качестве FW он тяжеловат. Но его можно растащить на компоненты. В Сети много материалов как прикрутить его к тому же CodeIgniter, у которого библиотека слабовата.
      • +1
        Вы имеете в виду реализацию MVC?? Характеристика «тяжеловат», сами понимаете, сильно зависит от ситуации и не является критерием для отсева.

        P.S. И коль уж назвались «сравнением»:
        Цель любого такого сравнения — помочь человеку определиться, что ему выбрать из многообразия имеющихся инструментов. Исключая из сравнения продукты далеко не аутсайдерские (Symfony & ZF) автор (ИМХО) оказывает в каком-то смысле медвежью услугу.
        • –1
          Жрет ресурсы.
          • –1
            Какие ресурсы? Боже упаси…
          • –1
            Выкиньте нахуй свой hello world.
            • –1
              Нахуй! Я сказал: «Нахуй!»
        • 0
          Разработчику надо самому определяться. На то он и разработчик.

          К слову:
          Недавно мне дали один крупный проект. Отдельно руководством выделялось время, чтобы конкретно я решал между ZF и Symphony. Прямое сравнение фреймворков определило всего лишь последовательность, в которой мне самому уже приходилось разбираться со всеми необходимыми для проекта тонкостями.
          Было желание написать данный проект на Yii, но руководство запретило из идеалогических соображений. В результате я выбрал Symphony.

          Так что, если есть возможность выбора — лучше самому вникнуть и решить.
          • 0
            А мне понравился подход — symfony именно как фреймворк (каркас приложения — MVC, роутинг, генераторы, тесты и т. п.), а из ZF используем «функциональные» классы
    • 0
      а на нем у автора helloworld не запустился вообще
  • –4
    Полезный материал, спасибо
  • +6
    А помоему эта статья была проплачена тому забугорному блогеру. У них это нормальная практика. И платил однозначно Yii.
    • 0
      У меня аналогичная точка зрения, у Yii всё отлично, а у других проблемы имеются.
      Видимо не захотели освещать другие стороны.
    • 0
      Уй действительно оч. хорош. Он намного проще Cake в изучении и намного богаче CodeIgniter'а по функционалу. Если бы пришлось выбирать сейчас — выбрал бы его. А так жалко наработки бросать.

      А статья — бяка.
  • –1
    Огромное! огромное! огромное! спасибо! Я новичок в РНР, всегда хотел увидеть сравнение РНР-фреймворков, что бы выбрать лучший!
    • 0
      Советую посмотреть еще как минимум в сторону Zend Framework и symfony. Да и от CakePHP не отказываться только на основании этого обзора. А как новичку лично я бы порекомендовал symfony или CakePHP (в них сложнее, имхо, написать «плохой» код), а уж потом разбираться с CI и пр.
    • +3
      это не та статья, на которую можно полагаться в выборе фреймворка
  • +2
    Все фреймворки поставляются с дефолтным оформлением и CSS. В целях тестирования мне пришлось избавляться от этого, чтобы каждый фреймворк делал только то, что требуется. Вот зачем было повторять эту фразу? Или это чтобы окончательно убедить читающих, что все фреймворки поставляются с дефолтным оформлением и CSS. В целях тестирования мне пришлось избавляться от этого, чтобы каждый фреймворк делал только то, что требуется? Если второй вариант, то теперь я точно знаю, что все фреймворки поставляются с дефолтным оформлением и CSS. В целях тестирования мне пришлось избавляться от этого, чтобы каждый фреймворк делал только то, что требуется.
    • 0
      :)
      Да, эта фраза меня тоже напрягла, но решил не вырезать в целях сходства с оригиналом.
      • +1
        :) Ну лучше было бы наверное убрать. Фиг с ним со сходством — читать ведь трудно. Я сначала подумал, что окно наверх случайно перемотал.
  • 0
    О Пирожке:
    Простота — проблем с установкой не возникло, написал блог пример за 10 минут. Все зависит от «сервера» :))
    Документация — хромает на обе ноги, это го не скрыть (на дворе 1.3, а все доки о 1.1), дельных советов мало :(
    Производительность — мне кажется на мелких проектах, роли вообще не играет, заметно быстрее Зенда
    Гибкость — есть магия, и она просто супер, но блин пока в неё вникнешь, нужно много выкурить манов и нервов :) Дальше хуже когда начинаешь работать со сложными БД, там все связать уже проблема, вся красота куда-то прячется. Работа с массивами отдельный респект. Обертки тоже очень помогают!
    Контроль доступа — полный провал, разобраться во встроенном так и не получилось, писал свой
    О «Безопасности» тяжело сказать, её реализация на стандартном уровне (может ниже), в зенде гораздо выше
    Разработка и поддержка — складывается впечатление что о нём только говорят, но ничего для него не делают, а если делает, то 1-2 дня в месяц :(

    • –1
      о чем вы?? доки для 1.2 уже давно есть, гибкость тоже на высоте, для сложных БД придумали Containable(http://habrahabr.ru/blogs/php/38675/), контроль доступа — я разобрался за день, теперь все ваще шикарно
      разработка и поддержка: https://trac.cakephp.org/timeline
      • –1
        плюс еще очень активный irc (200-300 человек онлайн), так же там постоянно сидят разработчики. буквально только что с одной из них решили хитровыжужженную проблему с контроллерами в плагинах.
  • 0
    ну а Symfony уже устарел? можно было его включить в обзор.
    А ао существу — так я вообще непонимаю для чего тесты проводить фреймворка, который только «Hello world» показывает?!
    Прелести фреймворков совсем в другом, а для этого теста нужно было использовать CMS.
  • +1
    CodeIgniter имеет возможность работать с так названными «подготовленными выражениями» (prepared statements). В случае с CodeIgniter они называются Query Bindings и справляются со своей задачей потрясающе.

    А еще там есть такая замечательная вещь, как ActiveRecords, которой я не пользуюсь :)
  • –3
    Спасибо за обзор
  • +1
    хоть и выглядит как галопом по европам, но достаточно познавательно, было бы интересно чтобы не флейм начался, а кто-нибудь появился и рассказал про Yii, как он в проектах, скорость разработки и есть ли острые углы.
    • 0
      о чем и речь, если хочется рассказать про фреймворк нужно про него и рассказывать. как в нем хорошо, а не как в других плохо.
  • +3
    А почему ни кто не упомянул про Kohana? kohanaphp.com/ habrahabr.ru/blogs/kohanaphp/
    Наша контора в начала сидела на КИ, но потому перешли на Kohana. Работаем уже больше года.

    Очень очень положительные впечателения. Все прелести CI + плюшки
    * не поодерживается php4 а значит на всю катушку используется фичи php5
    * очень продуманая и гибкая архитектура. если припрет можно переопределить почти все системные библиотеки
    * действительно качественный код

    Сообщество пока что меньше, чем у кейка или CI но вышеописанные фичи с лихвой окупают это
    • +3
      напишите по пунктам статьи о кохана, тогда и сравним ;)
      • 0
        пару статей сравнения Kohana и Ci можно найти в моем блоге
        andrey.opeykin.ru
    • 0
      Документация не поспевает за кодом…
      • 0
        Я бы даже сказал за кодами… :)
    • 0
      Начинать тяжело ИМХО. Если уж автор не разобрался в более хорошо документированных фреймворках…
  • +2
    Сравнение фреймворков, по хелло-вордам, напоминают сравнения машин, ударом ногой по бамперу.
  • +1
    ламерское сравнение :-) документация cakephp явно была просмотрена «по верхушкам», как говорится. и на основании это делаются какие-то выводы: ну вы даёте.

    про yii ничего не могу сказать, а codeigniter сильно не дотягивает до cakephp. хотя и быстрее. это единственное его преимущество.
  • 0
    По-моему, не затронули такую важную вещь как функциональность, наличие определенных компонентов по-умолчанию, за исключением контроля доступа.
    • 0
      Да, но стоит принять во внимание, что Yii только-только появился, а Cake и CI существуют уже много лет и успели обрасти комьюнити и, соответственно, дополнительными фичами.
  • 0
    У меня вопрос, если позволите. Кто из перечисленных умеет делать нормальный scaffolding чтобы использовать его как основу для бэкенда? Кекс вроде умеет, насколько знаю (джанго, рэйлс и его php вополщение «акелла», тоже).
    • 0
      Кекс точно умеет, но вот как основу… На любителя, наверное :)

      P.S. А «акелла» это кто?
      • +1
        >Кекс точно умеет
        это я, как бэ, в курсе :)

        акелла- akelos.org
        • 0
          Написали «вроде», а я, что точно :)

          За ссылочку спасибо, поковыряюсь, думал, что симфони ближе всех к рельсам (и скаффолдинг в симфони намного больше кейковского понравился, кстати)
    • 0
      codeigniter умеет. глава scaffolding называется
  • 0
    Мда, автор явный новичек в плане использования php-фреймворков, а уже сравнивать пытается, неразобравшись толком.
  • 0
    я недавно сам провел тесты с «Hello World» между Kohana Codeigniter и Yii

    если интересно welcome andrey.opeykin.ru/performance-kohana-codeigniter-yii/
  • 0
    Такое ощущение что автор изначально настроен против CakePHP.
    Более того не указана версия и примеры тестов, чтобы любой мог их повторить.

    Человек пишет нелепые вещи, например об авторизации, которая в cake делается с помощью Auth компонента в 5 строчек.

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

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

    А тесты от Yii это дейтвительно очковтирательство, чем автор это и поддтвердил.

    Судя по фразе «CakePHP требует создания модели, базы данных и таблицы, даже если они не используются в вашей программе» я делаю вывод что тест автора для cake тоже не верен.
    Достаточно указать $uses=array(); в контроллере и модель не будет создаваться.

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

    Ладно оставим это на совести автора, а статье — жирный минус.
  • +1
    Какая гадость. Какакя гадость эти дилетанские заметки в поисках дешевой популярности.
    Может прежде чем переводить стоило разобраться насколько автор владеет вопросом?
    Тем более он в первых строках вроде написал что НЕ разбирается ни в одном из представленных фреймворков, так что претензия в основном к переводчику. Я увидел просто какое то облако дезинформации, в котором даже копаться неприятно. Да, поначалу ещё более менее корректно сравнение качества документации и легкости установки. Это может сравнить и дилетант. Но дальше, дальше какие то голосовные выводу основанные на «насколько я знаю, как мне известно и т.д.» Не знаешь — не лезь.

    CodeIgniter, например, просто повернут на безопасности. Причем включается она 2 словами в кофиге. True+True. Поле этого Боб не то что не получит запрос сервера о переводе 10000 долларов на сайт Евы. Боб даже не заметит что какой то *дак НАСТОЛЬКО банально пытался подсунуть ему дешевую ссылку.

    Вобщем отвратительно.
  • 0
    Не знаю, конечно, что автор подразумевал, когда писал о поддержке параметризированных запросов, но касаемо поддержки оных в CakePHP и CodeIgniter он явно поторопился.

    CakePHP — Sanitize,
    CodeIgniter — codeigniter.com/user_guide/database/queries.html

  • 0
    Кстати, я сообщил автору о переводе его статьи и он поглядывает сюда, и даже хотел бы поучаствовать в дискуссии:

    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.
    • +3
      че, инвайт ему выслать?
      • –1
        Да нет, не думаю, что это нужно :)
    • +1
      Cake не такой простой и не такой быстрый как остальные, но он позволяет, IMHO, кодировать проще. Вы потратите неделю на изучение, но за месяц напишите больше. И еще, попробуйте symfony.
      • 0
        Да, я в свободное от работы время ковыряю симфони. Уже вторую неделю (выходные, холодные зимние вечера). Мощный инструмент, который действительно позволяет сосредоточится на более специфических задачах. Да, требует хорошего понимания ООП, знания английского (а куда без него нынче) и выдержки — потому что дочитать книгу до конца порой трудно, не сорвавшись и не начать кодить какое-то приложение, но останавливаю себе тем, что если не дочитаю, то буду изобретать велосипед используя велосипед:)

        Статья очень поверхностна, и мне кажется что выбраны фреймворки не очень высокого уровня (Cake не в счет). Сравнивать такие инструменты на хелло вордах — бессмысленно (выше уже сказали много по этому поводу), а то что фреймворк тяжел к пониманию и освоению не делает его плохим — «Тяжело в учении, легко в бою».
  • 0
    Не могу пройти мимо)

    Про проблемы с .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. на Хабре обычно переводы оформляют как топик-перевод.
    • 0
      +1 про шрифт. Причем там даже не Courier New, а просто Courier. )
  • 0
    «Я думаю, что отсутствие подготовленных выражений — это наиболее серъезная проблема 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 мануале, где описаны доп параметры и т.п. и что стоит по умолчанию

  • 0
    Спасибо за материал. Есть вопросы по безопасности.

    Про 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 во фреймворках.
    • 0
      По поводу hmac: от сниффера, конечно, hmac не спасет, но мне думается, что он поможет от тупого брутфоса. В случае обычного md5, отсниференный хеш тут же суется в какой-нибудь md5decrypter.com — и с большой долей вероятности имеем наш пароль (или что там у нас было закодировано). В случае hmac — необходимо знать еще и секретный ключ.
  • 0
    Спасибо за своевременную статью — как раз собирался делать новый проект. В качестве альтернативы и для общего развития попробую сделать это на yii.
  • 0
    Ну что за идиотизм! Не являюсь фанатом CakePHP, однако:
    1. Не было проблем с порогом вхождения, так как вначале прочел документацию.
    2. После прочтения доков было понятно где что лежит и что заменять.
    3. В CakePHP не требуется наличие базы и модели для контроллера — в доках написано, как отключить в своих экземплярах контроллеров.
    4. График с АРС показывает более чем двухкратное превосходство YII — и это «тяжело утверждать об преимуществе в скорости».
    Этих примеров хватило, чтобы поставить под сомнение ценность статьи для меня.
  • 0
    На самом деле в кейке всё довольно легко и логично, а строгость позволяет легче работать в коллективе. Однако, на счёт ACL соглашусь, требует вникания :)
  • 0
    Не понял н4х нуженo ещё новое чудо ЯШШ | YII?
    все существующие фрамеворки с недостатками!
    если бы был хороший, то был бы только он один.

    (думаю что Zend всех в61363т потихонечку)
  • 0
    Сравнение производительности PHP-фремворков с изменением количества подключений к базе Тут. Как видим «Hello, world!» и реальные приложения — несколько разные вещи.
  • 0
    Для аутентификации и авторизации в Code Igniter можно использывать эту библиотеку
  • 0
    Хочу рассказать про свой опыт.

    Необходимо было реализовать один проект. Но его особенность было то, что нет четкого ТЗ и четкого представления что должно быть и даже не было четких представлений о том какие связи между сущностями (один ко многим. многие ко многим). Был написан каркас на Yii + механизм распределения прав доступа по действиям с привязкой к ролям…

    Но когда потребовалось создать механизм ногошагового заполнения данными 5-6 сущностей, котореы завязаны друг на друга — я с этими relations повесился…

    Взял склет проекта на CI и переписал за двое суток аналогичнй функционал…

    код игнитер 2.0 рулез )
  • 0
    Хочу рассказать про свой опыт.

    Необходимо было реализовать один проект. Но его особенность было то, что нет четкого ТЗ и четкого представления что должно быть и даже не было четких представлений о том какие связи между сущностями (один ко многим. многие ко многим). Был написан каркас на Yii + механизм распределения прав доступа по действиям с привязкой к ролям…

    Но когда потребовалось создать механизм ногошагового заполнения данными 5-6 сущностей, котореы завязаны друг на друга — я с этими relations повесился…

    Взял склет проекта на CI и переписал за двое суток аналогичнй функционал…

    код игнитер 2.0 рулез )
  • 0
    Что вы не совсем проникли в CakePHP, или может документация стала лучше, во многом в его сторону не согласен с вами. Особых сложностей что избавиться (впервые!) со стандартной темой не было, что несколько отображений из контроллера одна строчка render(); что других проблем, на мой взгляд сильные соглашения в кэйке способствуют что следующий разработчик увидев код и зная эти соглашения быстрее поймет его и сделает также для другого, а не как хочет, а потом сиди копай что тут программист хотел и что с чем связано.
    В общем я не жалуюсь на CakePHP. Заинтересовался и собственно узнал о нем на собеседовании где с Code Igniter собрались переписывать на Yii. Тем самым стоит предположить что Code Igniter хуже Yii, первым фактором сослались на производительность.
    • 0
      … и собственно узнал о нем… — об Yii :)
  • 0
    Для меня CI оказался самым простым, лёгким и понятным)

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