Какой PHP фреймворк вы используете? И почему?

     
    Какой PHP фреймворк вы используете? И почему?
    • 15.5%Yii362
    • 9.7%Symfony227
    • 19.6%Zend Framework457
    • 8.5%Kohana198
    • 14.2%CMS-CMF (Joomla, Wordpress и т.д.)331
    • 12.9%CodeIgniter302
    • 4%CakePHP94
    • 24.7%Самописный фреймворк577
    • 29.2%Пишу на PHP, но не использую фреймворки.681
    • 3.1%Другой, отпишу в комментах73

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

    Поделиться публикацией
    Похожие публикации
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама
    Комментарии 238
    • +2
      Интересна текущая расстановка сил на рынке веб-фреймворков на PHP. Опрос решил сделать после прочтения вот этого топика. Хотелось бы узнать пристрастия хабрасообщества, и их причины. Если варианта нет, пишите в комментах — добавлю. Если остановитесь на пункте «CMS-CMF», было бы интересно узнать, почему не юзаете «полноценный» фреймворк. Прошу не разводить холиваров, выбор рабочего инструмента — личное дело каждого, было бы интересно узнать причины этого выбора.
      • +3
        расстановка сил не свяана с количеством пользующихся фреймворком. Допустим, у Symfony один из самых высоких порогов входа, соответственно пользуются меньше, но он пожалуй, самый сильный из представленных. В то же время части из Zend Framework применяются совместно с Symfony.

        p.s. Кстати, есть ещё огромная библиотека PEAR, которую тоже бы следовало включить в список.
        • +1
          полагаю, что фреймворки более популярны в сравнительно узком сегменте коммерческого коммандного программирования.
          для php в целом, как основного языка веб-разработки-- больше доля фрилансеров-одиночек, чаще выбирающих «чистый php» плюс «свои наработки», (которые, как правило, не хочется определять столь громким термином, как «фреймворк»))

          • 0
            По-моему наоборот, крупные (и не очень) коммерческие разработчики используют готовые фреймворки как таковые (каркасы приложений, где, грубо говоря, код пишется где-то между точкой входа и ядром, а не набор полезных компонентов) реже, чем фрилансеры-одиночки, не ограниченные в выборе средств ни корпоративными политиками, ни лицензионными ограничениями, но ограниченные временем на разработку. Другое дело, что часто и фрилансеров ограничивают (банальный пример — заказчик не может понять зачем ему 10 Мб кода на обработку формы и админку к ней, по крайней мере пока не покажешь ему админку и форму, созданные скаффолдингом буквально за 5 минут), или они ограничивают себя сами из-за плохой лени.
            • 0
              Ой вы не правы.
              Работаю в СЕО компании. Через меня проходят дюжины сайтов.
              И как вы думаете что доминирует?

              Ага CMS: Joomla, WordPress (и сайты на нем делают), WebAssyst, Netcat, Modx

              Самописок мало (3 сайта, если отбросить html сайты), на фреймровках еще меньше. За 8 месяцев работы пришел 1н на смарти, 1н на код-игнайтере.

              • 0
                CMS в контексте своего коммента выше вы относите к фреймворкам или чистому php со своими наработками? :) Если к первым, то да, не прав :)
                • –1
                  VolCh
                  Я хотел сказать своим постом что

                  По-моему наоборот, крупные (и не очень) коммерческие разработчики используют готовые фреймворки как таковые

                  никакие фреймворки они не используют, в 85% случаях CMSки.
        • 0
          Что вы вкладываете в понятие «полноценный»?
          Вот Друпал на сколько не «полноценный»?
          • +1
            «Полноценный» в моем понимании — чистый CMF, Drupal это всё-таки больше CMS система.
            Ряд CMS, предоставляющих API для расширения своей функциональности, претендуют на звание CMF, хотя провести чёткую границу между CMS и CMF порой сложно. К примерам CMF, также являющимися готовыми CMS, можно отнести такие системы, как Plone, MODx, Drupal, eZ publish или TYPO3.
            Wikipedia
            • +2
              Странно
              Чистый CMF полноценный, а CMF предоставляющий также возможности CMS — уже не полноценный.

              Я сегодня такое же про универсальность Друпала читал, он не универсальный, потому что можно настроить и донастроить всё и ещё больше.

              Друпал ровно такой, как его используют. Максимально использовать возможности сторонних модулей или пользоваться API системы и своими модулями — выбор разработчика.
              • 0
                Я специально слово «полноценный» в кавычки взял.
        • +17
          Долго ждал такого опроса. Так как встала проблема выбора фреймворка для изучения и дальнейшей работы с ней.
          Предварительно уже выбрал Yii и начал изучать документацию, надеюсь не ошибся. В любом случае очень интересно посмотреть на чем люди пишут.
          • +10
            Не ошиблись, скорость разработки на Yii очень высокая и он динамично развивается + хорошее русскоязычное сообщество.
            • +3
              Только вот плохо уроков мало. Одного примера с созданием блога на их сайте явно мало. Скринкасты выглядят суховато. Но я надеюсь все это придет со временем.
              Да и с опытом думаю все это придет, главное начать что-то делать.
            • 0
              Что-нибудь слышно, когда в YII на PHP 5.3 namespace нормальный перейдут? А то CClassName утомляет…
              • 0
                Чем? Были реальные случаи конфликтов? Разве не будет больше утомлять писать каждый раз yii/base/ClassName?
                • 0
                  use спасает от каждого раза :) Да и читаемость, имхо, увеличивает, даже если используется класс только один раз.
                  • +2
                    Таки походу не слышно.
                    Утомлять не будет, есть use, есть автолоад и приятное чтение и понимание где и что лежит.
                    • +2
                      Да не, это-то всё ясно. Просто текущая версия умеет делать autoload с namespace-ами. В стороннем коде пространства имён полезны, а вот в коде самого фреймворка…
                  • +2
                    На сайте написано, что возможно, альфа выйдет в декабре.

                    А так, префикс С меня не напрягает, для своего кода можно без проблем использовать неймспейсы. Анонимные функции для событий реализованы, не хватает только Late Static Bindings для моделей, но это не критично.
                • +9
                  Yii очень хорош.
                  Основной функционал при MVC подходе развит (Авторизация, пользовательские настрйки, права)
                  + он не тащит груза php 4той версии.

                  У него одно плохо. Клиентсайд ужасный. Лучше его не использовать.
                  Эвенты навешиваются отвратительно. Все что подгружается с помощью аякса, глючит, если использовать с вложением друг в друга.
                  • +6
                    А как оно правильно читается?

                    -на чем пишешь?
                    -на «иайай»

                    или так
                    — на «иеее»

                    а может так
                    — на «иии»

                    в общем название любопытное

                    • НЛО прилетело и опубликовало эту надпись здесь
                      • +1
                        еще вариации):
                        — вайайай
                        — йыыыы
                        • +1
                          Вайайай — на кавказе название любого фреймворка, который почему-то не хочет работать :)
                        • +3
                          Достаточно скринкаст послушать.
                          • +12
                            Мы называем «юи», или:
                            — на чем писать будем?
                            — на уях!

                            :)
                            • +21
                              А у нас вошел в оборот устойчивый фразеологизм "Yiiбошить сайты" :)
                              • +1
                                гуи на уях
                          • –22
                            Может, отдельно еще вынести Bitrix?
                            • +13
                              Думал об этом, а не она не относится к CMS-CMF?
                              • 0
                                Относится-то относится, но в этом пункте получается уж очень много разных систем, каждая из которых имеет своих поклонников и противников.
                                • +4
                                  Ну да, но тогда бы это всё превратилось в опрос про CMS.
                                • 0
                                  Относится. Но всё-таки в конце есть буква «F».
                              • +2
                                На пхп в основном использую cmf drupal, что то больше предпочитаю написать на Python&Django.
                                • –3
                                  Не использую фреймверки.
                                  Для небольший сайтов с парой, тройкой функций не вижу смысла тянуть целый фреймвёрк.
                                  Для игрового проекта также решил не использовать фреймвёрк. Я сделал свою простую архитектуру, без излишеств.

                                  Я за индивидуальный подход в собственных проектах и разработке простых сайтов. Фреймвёрк лишь усложняет структуру, порой приходится натыкаться на чужое слабоумие (лучше дело иметь со своим).

                                  ИМХО, чем больше проект завязан на структуру стороннего разработчика, тем сложнее делать в нём изменения. Для многих вещей приходится писать свои адаптеры и прокси. Что касается библиотек — их нужно использовать по мере возможности, так как они не задают общей структуры и их легко заменить.
                                  • +28
                                    Вот как раз для небольших сайтов фреймворки использовать удобнее, имхо. Для них количество «инфраструктурного» кода (роутинг, работа с формами, валидация, кэширование, шаблонизация, доступ к БД, админка и прочая) велико по сравнению с собственно логикой сайта. Фреймворк всё это предоставляет, зачастую абсолютно прозрачно и с минимальной привязкой к фреймворку, например только в коде контроллера, где происходит связка модели и вида/шаблона.

                                    Если по мере развития проекта излишняя универсальность (а значит и неизбежный оверхид)фреймворка становится проблемой, то заменяются отдельные компоненты на самописные. Первый кандидат обычно DBAL/ORM — универсальные механизмы заменяются на СУБД- и схемоспецифичные, но эти изменения строго локализованы, а не размазаны по всему проекту. И особой привязки к «навязанной» схеме нет — модели и контроллеры обычные «plain old PHP objects» ни к чему не привязанные, ни от чего не наследуемые, сам фреймворк работает с ними интроспекцией и рефлексией, но вам никто не мешает реализовать более эффективные способы, пускай и более привязанные к вашей задаче.

                                    Не использовать фреймворки, по-моему, имеет смысл как раз на крупных проектах, где инфраструктурного кода заведомо много меньше основного и при использовании фреймворка его всё равно придётся менять на более эффективный в конкретных условиях, оставив от оригинального фреймворка по сути только каркас :) и, может быть, незначительные по оверхиду компоненты типа валидации форм и интернационализации. И то, возможно, имеет смысл использовать готовый фреймворк, предложив (если речь об open source) свои реализации критичных компонентов с теми же интерфейсами сообществу, не затрагивая другие. Или предложить расширить интерфейсы, если вам кажется, что существующие уж очень сильно вас связывают или дают значительный оверхид.
                                    • –10
                                      Как раз переферийный код в небольших проектах сводится лишь к DAO/ORM. Остальной код затачивается под конкретную задачу, ибо универсальность не нужна.

                                      Например нужно написать магазин для цветочной лавки. Нужно:
                                      1. Список букетов (изображение, цена, кнопка купить)
                                      2. Форма отправить заказ (простая мейл форма со списком покупок)
                                      3. Форма отслеживания заказа
                                      4. Форма редактирования списка

                                      Список товара делается одним SQL запросом и for(), который формирует страницу
                                      Текущий список заказа хранится в сессии
                                      Адресс, телефон, имя передаются через форму и сохраняются одним SQL запросом.
                                      В три строчки отправляется письмо.
                                      Еще один SQL запрос формирует запись о заказе. ID используется для получения статуса.

                                      Зачем тут фреймвёрк? Что бы «шкурки» менять для разных магазинов? Проще сделать пару функций с общей структурой и параметром "$cssClasses", и потом просто добавить в новый дизайн.
                                      ORM тут вообще не нужен. Максимум DAO, что бы перекрутить на другу бд. Капча, отправка письма — используем пару библиотек. Редактор списка тоже форма с двумя запросами (удалить, сохранить).
                                      Проверку логина, пароля можно вообще средствами httpd сделать, но и свой написать не сложно (я про логин в «админку»)

                                      Захотели добавить поле описание к товару: поправили запорос, поправили функцию отображения.

                                      Используя фреймвёрк мы получим лишний «жир» в виде ненужного функционала + баги в нём.

                                      Фреймвёрк нужно использовать при поточном производстве схожих проектов, и лучше написать свой — который будет максимально подходить именно под этот тип проектов, а не иметь встроенный блог, чат, голосование, RSS для корпоративного сайта с документацией.

                                      • +8
                                        Список товара делается одним SQL запросом и for(), который формирует страницу… В три строчки отправляется письмо.
                                        Еще один SQL запрос формирует запись о заказе. ID используется для получения статуса.

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

                                        А теперь представьте, что вам надо переименовать столбец в БД, если у вас куча таких запросов.
                                        Зачем тут фреймвёрк?

                                        Для увеличения гибкости веб-приложения, для открытости изменениям, для лучшего контроля управления в программе и возможности не писать велосипеды, а использовать готовые, которые оттестированы и оптимизированы.
                                        • –6
                                          Зачем цветочной лавке гибкость? Она предполагает торговать вооружением разных типов и разных сборок?

                                          В ТЗ есть «написать простой магазин», так зачем писать его расширяемым? Нужно решать конкретную задачу.

                                          Когда встанет задача расширения (не единоразового добавления поля), тогда и надо думать про фреймвёрк, движок и рефакторинг. Пока требуется делать просто, надо делать просто.

                                          Из задачи видно, что кучи полей не предполагается.

                                          Но подходы безусловно разные могут быть, даже и в простецких задачах. Но всё же советую вдумываться в поставленную задачу и её перспективы =)

                                          • +4
                                            А зачем вы данные от логики будете отделять? Разве в ТЗ сказано, что вёрстка будет изменяться? Но вы вводите функции отображения, а не пишете всё в одном файле в глобальной области видимости, хотя так будет эффективнее.

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

                                              Так и тут — зачем мне тянуть фреймвёрк, настраивать его, отключать ненужный функционал, что бы потом может быть когда нибудь его включить?

                                              • 0
                                                Если кофемолка стоит столько же, а то и дороже, то почему нет? И уж точно я вручную не молю кофе :)

                                                Исхожу из того, что даже для такой фигни как в примере, не дольше создать приложение под фреймворком (если не в первый раз его используешь, конечно), чем с нуля. Зато потом, если понадобится, что-то что отключили, то достаточно будет только включить, а не писать опять с нуля или переводить на тот же фреймворк.
                                                • +2
                                                  когда вам нужна кофемолка — вы же не покупаете кухонный камбаин? Хотя он тоже умеет молоть кофе.

                                                  Суть именно в том, что вы можете взять кухонный комбайн и сделать из него кофемолку или что-то другое — неважно. Использовать фрейм — хорошо, тут и спорить не о чем. Вопрос в другом, один кодер хорошо разобрался в фрейме и будет использовать его возможности по полной, а другой — потратил 10 минут лишь на беглое прочтение quick start guide и сел кодить с полной уверенностью что он все знает. Тут то и начинаются разногласия. Первый кодер осознал архитектуру фрейма, второй — нет. Первый будет по полной использовать возможности фрейма, второй поймет, что затраты на изучение фрейма того не стоят и выбросит его, свалив все на его «дурацкую и запутанную архитектуру».
                                                  Сравнение фреймворка с готовым комбайном — неверно. Я бы скорее сравнил его с набором инструментов. Наглядный пример: есть задача смастерить тот же кухонный комбайн, есть набор качественных, проверенных многими инструментов, есть желание. Я думаю лишь о решении задачи, более мне ничего не мешает, пользуюсь инструментами которые у меня имеются, все чисто и гладко. Теперь проведем аналогию, когда мы пишем с нуля (и\или имеем никем не проверенную, «мощную» (с нашей точки зрения) архитектуру). Пример с тем же комбайном: есть задача смастерить кухонный комбайн, есть набор инструментов сделанный собственными руками, но еще ни разу не проверенный на деле, сомнительного качества, мы точно не знаем какие инструменты нам понадобятся, но думаем что для решения задачи хватит того что есть. Начинаем созидать и понимаем, что многого не знали и наши инструменты нужно допиливать и допиливать. Время идет, а мы все дорабатываем свои инструменты, вместо того чтобы решать поставленную задачу. Жена все время пилит: «Вася мне нужен кухонный комбайн!!! >_<», а вы все ломаете голову как сделать ключ на 8 :)
                                              • 0
                                                А зачем ездить на машине ведь есть велосипед?)
                                              • 0
                                                Вы сейчас ООП описали
                                              • +1
                                                >Зачем тут фреймвёрк?

                                                Чтобы написать всё это быстрее, чем с нуля :)
                                                • –3
                                                  Для такой фигни как в примере фреймвёрк займёт больше времени.
                                                  • +3
                                                    Don't shave that yakk:
                                                    sethgodin.typepad.com/seths_blog/2005/03/dont_shave_that.html

                                                    Статья на английском, но вкратце: занимайтесь решением своей задачи, не тратя времени на детали и мелочи, которые эта задача порождает.

                                                    А по большому счету — используйте опыт тех, кто уже наступал на грабли и проложил дорожку вокруг них в виде фреймворка… и даже заборчик поставил.
                                                    • +2
                                                      >Для такой фигни как в примере фреймвёрк займёт больше времени.
                                                      Складывается впечатление, что вы просто не работали (основательно) ни с одним фреймворком или просто путаете его с CMS
                                                  • +4
                                                    Фреймвёрк нужно использовать при поточном производстве схожих проектов, и лучше написать свой — который будет максимально подходить именно под этот тип проектов, а не иметь встроенный блог, чат, голосование, RSS для корпоративного сайта с документацией.

                                                    Уважаемый, Вы уверены, что знаете что такое фреймворк? Вы не путаете его в CMS?
                                                  • 0
                                                    имеет смысл использовать готовый фреймворк, предложив (если речь об open source) свои реализации критичных компонентов с теми же интерфейсами сообществу, не затрагивая другие. Или предложить расширить интерфейсы, если вам кажется, что существующие уж очень сильно вас связывают или дают значительный оверхид.

                                                    Вот это называется ZF-way (говорю безотносительно к фреймворку, в Ruby on Rails, Symfony и т.д. пропагандируется тот же принцип, этакое всеобщее благо и совместная community-разработка). Почему программисты не идут по этому способу, а в большинстве своем хардкодят?
                                                    • +1
                                                      Возможно потому что наивно считают себя гениями, которые объемный код напишут и, главное, отладят в одиночку быстрее, чем сообщество :)
                                                      • +1
                                                        А, вот ещё забыл. «Гении» как правило работают в одиночку, поэтому забивают болт на то, что возможно со временем над проектом будет работать ещё кто-то. В общем, юношеский максимализм такой :)
                                                • +7
                                                  >Фреймвёрк лишь усложняет структуру
                                                  Фреймворк скорее предоставляет «инструмент», а структуру вы строите сами.
                                                  • +2
                                                    Блин, я конечно хотел написать ответ на коммент chernser (но промахнулся).
                                                    • +3
                                                      ИМХО, фреймворк — гибкий каркас, чтобы не делать спагетти-кода, и чтобы он не скатывался в пластилин.
                                                      • 0
                                                        В большенстве случаев приходится подстраиваться под этот «интсрумент».
                                                        Например, нет смысла писать свой DAO, когда уже есть слой доступа к БД во фреймвёрке, но иногда этот слой не соответствует извращенным требованиям проекта и пишется свой костыль, всё равно.

                                                        • +5
                                                          Без использования фреймворка вы бы этот костыль всё равно писали бы.

                                                          А подстраиваться под стандарты — это в первую очередь сдерживать свою дурную голову и учиться на тех решениях, в которых месяцы человеко-часов работы людей совсем не глупых.
                                                        • +2
                                                          Фреймворк предоставляет инструмент и задает типовой каркас приложения. Наличие типового каркаса снижает стоимость вхождения в проект.
                                                          • 0
                                                            При условии, что этот типовой каркас известен входящему или хорошо задокументирован :) Как-то так получается, что у «самописных» фреймворков с этим хуже, чем у популярных.
                                                        • +1
                                                          Исторически сложилось, что выбирать в 2001-2003 годах особо было нечего.
                                                          Был mamba (сейчас joomla), появился первый Drupal
                                                          Изучал их для создания собственного фреймворка.
                                                          • –2
                                                            Я не знал о фреймворках, когда начинал изучать php и со временем наработал свой фреймворк (если конечно его можно так назвать). Сторонние фреймворки не люблю по причине того, что больше нравится писать на «чистом» php. Фреймворки делают почти всю интересную работу, но интересную лишь в целях образования (лично для меня), бывают случаи, когда нужно здесь и сейчас получить определенный результат, тут конечно единственный выход использовать фреймворк.

                                                            Еще заметил что в некоторых компаниях используется фреймворк, чтобы в команде не было недопонимания кода других участников.
                                                            • +3
                                                              Codeigniter. Низкий порог вхождения. Все основные функции имеются, небольшой размер.
                                                              • +2
                                                                тоже с него начинал, переползаю потихоньку на Kohana…
                                                                • +2
                                                                  Начинал также, переполз на кохану полностью, т.к. Codeigniter продолжал тянуть за собой php4. Прошел кохану 2 и 3.0, сейчас думаю попробовать 3.1
                                                                  • +7
                                                                    прошел тот же путь, уверяю — следующим шагом будет Yii :)
                                                                    • +1
                                                                      Вполне возможно. Но я его смотрел перед коханой 3, и решил пока остаться здесь =)
                                                                    • +2
                                                                      А я после CI переполз на yii — ни разу не жалею.
                                                                  • +1
                                                                    Я взялся за PHP, имея за спиной приличный опыт разработки на Java. Codeigniter расстроил наличием костылей в объектной модели. А вот Kohana 3 особых нареканий не вызвала. Использую в связке с Twig.
                                                                    • +1
                                                                      Гляньте ещё на symfony2 — знакомый джавист, глянув на мой код, сказал, что это практически Java, только $ в глаза бросается :)
                                                                      • +2
                                                                        называть переменные с баксом в самом начале можно и в яве ;)
                                                                        • +3
                                                                          Я лишь его слова передал :)
                                                                        • +1
                                                                          Да там много с java склонено, DI — Spring, Security почти один в один Spring Security, Валидация — JSR-303 кажется (даже в доках Symfony про это было), ну и Doctrine — Hibernate. Это то, что сходу вспомнилось.
                                                                          • 0
                                                                            Слышал мнение, что и сам PHP многое берёт у Java, оставаясь, конечно динамическим и т. п., ну и таща за собой много BC.
                                                                      • +3
                                                                        На работе достался проект на CI. Не понравился. Слишком тоненький, примитивный. Да и PHP4 чувствуется.
                                                                      • +3
                                                                        выбрали Yii
                                                                        пока всем довольны, правда, он немного сыроват
                                                                        • +7
                                                                          Давно все проекты делаем на Yii.
                                                                          Гибкость, легкость, скорость разработки возросла в разы. «сырость» в самой первой версии. сейчас, после нескольких апдейтов уже все починили и с ним нет никаких проблем.
                                                                          • –1
                                                                            если вы не замечаете проблем, это не значит, что их не существует :)

                                                                            зайдите в раздел «баги и предложения» на ру-сайте фреймворка
                                                                            • +9
                                                                              тоже самое можно сказать про любой фреймворк)
                                                                              проблемы и баги есть везде. это нормально.
                                                                              главное что Yii активно развивается, часто выходят новые версии, в которых все проблемы оперативно фиксятся.
                                                                        • –3
                                                                          Не использую фреймворки.

                                                                          Раньше работал с CodeIgniter, но со временем, когда набрался опыта, отказался от использования фрейморков.
                                                                          Фреймворки хороши на начальном этапе, когда опыт не позволяет писать сложные вещи. А потом, когда знания накопятся, лучше перейти на свои наработки.
                                                                          • +3
                                                                            Что вы думаете насчет, реализации своих знаний и опыта в расширения фреймворков (доп. библиотеки, модули, бандлы и т.д.)? Это позволяет делиться опытом.
                                                                            • +8
                                                                              > Фреймворки хороши на начальном этапе, когда опыт не позволяет писать сложные вещи.

                                                                              А по-моему это всё равно что сказать PHP/Ruby/Pyton хороши на начальном этапе, а сложные вещи нужно писать на С++. Существует НЕ так много проектов, которым нужен нестандартный каркас, 99% из них используют сразу всё из DB/ЧПУ/Logins/MVC/ORM/Cache (некоторые еще i18n/Forms), и фреймворки предоставляют всё это, плюс полезные вещи как дебаг панели и т.п. Работаю с Symfony и считаю архинеэффективным если бы я все эти стандартные вещи находил (писал?) и интегрировал/связывал сам.
                                                                              • +6
                                                                                CodeIgniter очень слабый фреймворк, решает проблем меньше, чем создает, из-за поддержки php4 много костылей, ORM нет(даже обертка для базы без нормального построителя запросов), хелперы недоделанные, автолоада нет, модульности нет, вывод вьюшки неоправданно усложнен… Я мы тоже забил на фреймворки, если бы не знал про Zend, Symfony, Yii.
                                                                                • +3
                                                                                  Можно про костыли CodeIgniter с примерами и чем он вас так тяготит с поддержкой php4?

                                                                                  А то все говорят такое, а примеров привести не могут, словно им запертили __constuct писать или свои паттерны фабрик использовать, перегружать классы и использовать кучу библиотек не тянущих php4.
                                                                                  • +3
                                                                                    Как минимум повсеместное использование глобальных фукций, можно было избежать извращений вроде «if (! function_exists('form_open')) {...}» используя статичные методы.

                                                                                    В коде куча полуоберток:
                                                                                    function view($view, $vars = array(), $return = FALSE)
                                                                                    {
                                                                                    return $this->_ci_load(array('_ci_view' => $view, '_ci_vars' => $this->_ci_object_to_array($vars), '_ci_return' => $return));
                                                                                    }

                                                                                    Если посмотреть как работают вьюшки, становится понятно, что сделать что-то аля yii/renderPartial можно только через костыль вроде «load_class('Loader', 'core')->view(...)», а из контента в layout нельзя нормально передать данные, кстати, работу с layout еще нужно написать.

                                                                                    > А то все говорят такое, а примеров привести не могут, словно им запертили __constuct писать или свои паттерны фабрик использовать, перегружать классы и использовать кучу библиотек не тянущих php4.
                                                                                    Чтобы привести хорошие примеры надо с _этим_ работать, осмотор кода показал что с _этим_ работать нельзя. Ничего не запретили, но сами использовать не стали, отсюда и вывод, написать хороший код на CI можно, но это займет не месяц, а год и от CI ничего не останется, проще сразу писать с нуля.

                                                                                    З. Ы. пробовал писать на CI года 3 назад, отказался в пользу Kohana и я смотрю не зря, с того времени CI не изменился.
                                                                                    • 0
                                                                                      Вас это напрягает? А то что использовать ООП лишь для namespace нет? :)

                                                                                      Ничто не мешает вам перегрузить эти стандартные функции.

                                                                                      Хотите вьюшек в Wiki лежит уже давно парочка библиотек для Twig, включайте. К чему идут все фрэймворки как к заменяемости желаемых компонент другими у CI есть.
                                                                                      • 0
                                                                                        Без ооп для неймспейса ломается ооп впринципе, т. к. из объекта нельзя без костылей создать глобальную функцию.

                                                                                        Зачем Twig, php сам по себе шаблонизатор. Все сводится к тому, что если писать на CI не хелло ворлд, надо менять большую часть компонентов фреймворка, шикарно, еще и без нормального ооп.
                                                                                        • +5
                                                                                          Ну и как все живут до 5.3 версии PHP пока namespace не было. Но обертывать кучу функций внутрь объекта это извращение всё же, чтобы потом юзать их статикой. Словно всё ПО на ООП пишется, нет, спокойно люди пишут и на СИ без ООП на PHP тоже можно без объектов писать, тем более где это не надо.

                                                                                          Ну вопрос по тому какой из PHP шаблонизатор с его дозволенностью во view использовать код это еще можно долго обсуждать. Добавить, а не заменить если так хочется вам partial шаблонизатора, вот выход с Twig.

                                                                                          У вас большой опыт CI? У меня более 3х лет, но я не меняю в нём большую часть компонент, а расширил его один раз закинув файлы в library — HMVС, MY_Model, MY_Router, ApplicationController, BackendController и работаю, пишу проекты больше че «хэлло ворлд», что я делаю не так?

                                                                                          Фрэймворк не панацея, он даже может быть не модным, иметь внутри не красивые кишки, но если он в ваших руках решает поставленные задачи быстро и с нужным результатом — он ваш. Нет ищите другой, ни один фрэймворк не панацея от кривых рук.
                                                                              • +3
                                                                                Zend и Fat-Free
                                                                                • +3
                                                                                  Ура, я не один на нём работаю!
                                                                                  Хотя, надо сказать, косяки в нём есть — при работе над мало-мальски сложным проектом они вылазят, но легко поправляются, плюс автор готовит версию 2.0, которая будет очень финтифлюшной, да и ещё с обратной поддержкой :)
                                                                                • +7
                                                                                  Drupal
                                                                                  • +4
                                                                                    Пробовал Cake, CI, ZF — остановился на symfony2. Правда показал свой код знакомому джависту, который когда-то писал на PHP3 и он спросил «а что тут от PHP осталось кроме $ перед переменными? Даже XML конфиги почти такие же портянки!» :)
                                                                                    • +6
                                                                                      Sf2 для продакшена? Может топик напишешь по теме Sf2? Думаю было бы многим интересно.
                                                                                      • +1
                                                                                        Думаю запустимся одновременно с релизом sf2 или даже позже. Тогда и будем делать выводы о том, как на продакшене живёт.
                                                                                        • 0
                                                                                          Имхо, Symfony2 стабильнее большинства кода который пишут, а АПИ, насколько я понимаю, зафиксирован.
                                                                                      • +15
                                                                                        Yes it is — Я думаю этим все сказано.
                                                                                        • +5
                                                                                          Kohana. Мне, по большому счету, от фреймворка нужна скорость, модульность, удобная структура для MVC и не нужны в базе всякие ORM-ы, генераторы HTML и прочее и прочее. Все это я получил.
                                                                                          • +1
                                                                                            можете еще пару слов о Kohana3 написать? Я вот просто посмотрел код одного проекта — вроде все понятно и ничего лишнего. Какие слабые места при разработке? (скорость работы, я так понял, нормальная).

                                                                                            Как там дела с namespace и прочими плюшками PHP 5.3? Просто ZF2 и Symfony2 сейчас еще в разработке, а Kohana подкупает что у нее стабильные релизы.
                                                                                            • +6
                                                                                              Плюшки PHP 5.3 вообще не используются и вроде бы как даже не планируются. Но вроде бы как на 5.3 работает нормально и не выкидывает DEPRECATED ошибки.
                                                                                              Kohana хороша, если вы хотите иметь полный контроль над фреймворком и готовы за это платить удобством. Тут нету из коробки кодогенератов, орм слабенький, нету миграций. Но вы взамен получаете очень быстрый и управляемый код. Переопределяется все — любой класс фреймворка, класс модуля, конфигурационный файл. Ничего не скажу по поводе генерации форм, валидации, работы с HTML, так как у меня все данные в json гоняются и я не сталкиваюсь с такими вещами.
                                                                                              Еще я бы хотел отметить высокое качество исходного кода. Если какого-то момента нет в документации — можно смело смотреть исходники и все очень быстро становится понятным.
                                                                                              • 0
                                                                                                Вы говорите что все данный в json гоняете — как же в итоге формируется UI у вас? Меня этот вопрос недавно интересовал, но глубоко зарыться времени нет :(
                                                                                                Можете поведать парой предложений? Ну или статьей (заметкой) на хабре или еще где :)
                                                                                                • 0
                                                                                                  UI у меня формирует Flash-клиент =)
                                                                                                  • 0
                                                                                                    Возможно имелось в виду следующее: передаем json в javascript (или используем json_encode() если js принимает данные в виде строки). А потом… json это же нативная конструкция для js, поэтому без проблем формируем UI
                                                                                                    • 0
                                                                                                      Нене, я-то как раз интересовался тем ЧТО собирает UI. Потому как в последнее время стали валиться заказы на RIA и вот просто времени нет изучать есть ли какие-то адекватные фреймворки для сборки UI на стороне клиента.
                                                                                                  • 0
                                                                                                    Поддерживаю во всёми сказанном. Добавлю, что использую его именно с php5.3, полёт отличный.
                                                                                              • +8
                                                                                                Начинал с CodeIgniter, потом по работе пришлось изучить Zend Framework. Привык к нему, полюбил… Немного толстенький он, некоторые моменты можно было бы сделать лучше, но в целом очень нравится. Думаю ещё в ближайшее время Yii посмотреть.

                                                                                                На новой работе пишу сайты на каком-то движке фирмы, писаном без фреймворка, без паттернов, видимо без рефакторинга. И это ад. У меня есть 20 сайтов на ZF — дай мне любой и я сходу скажу какой файл надо править, чтобы сделать нужный фикс. На сайтах без фреймворка(а соответсвтенно и без единой структуры, с отличающимся поведением классов ядра если такое имеется) приходится каждый раз вспоминать где, что, как работает.
                                                                                                • +1
                                                                                                  Я долго присматривался к ZF, считая его главным претендентом на промышленный стандарт. Но в конце-концов симпатии склонились в сторону Kohana 3. ZF действительно какой-то толстенький. Ko3 в общих чертах реализует тот же подход. Все то же самое, но проще. Как результат, более высокая производительность и низкий уровень вхождения.

                                                                                                  Полность согласен с тем, что навязываемая фреймворком структура проекта — великое благо. В чужой отсебятине ох как нелегко концы найти.
                                                                                                • +1
                                                                                                  Cascade framework. Он пока ещё находится в активной разработки, документации по нему практически нет, но фреймворк с большим потенциалом. Если кому интересно — github.com/gorbunov/cascade/
                                                                                                  • 0
                                                                                                    Зависит от задачи.
                                                                                                    Если что-то простое (скрипт) — не использую
                                                                                                    Посложнее — свой мини-фреймворк
                                                                                                    Ещё сложнее — мне проще подобрать готовое решение (CMS/CMF), которое иногда скрещиваю со своими наработками.
                                                                                                      • +7
                                                                                                        Yii + Zend

                                                                                                        Yii — когда надо быстро и без заморочек
                                                                                                        Zend — когда надо гибко, плюс довольно часто использую его по-частям, а не всем фреймворком целиком, например, Zend_Mail
                                                                                                        • +4
                                                                                                          Для диплома пишу на YII

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

                                                                                                          На прошлой работе был Битрикс, на новой — все полностью самописное.
                                                                                                          • +4
                                                                                                            Yii. Потому что он легкий, быстрый и очень хорошо документирован. И очень отзывчивое и компетентное русскоязычное сообщество. До этого использовала только голый PHP без фреймворков (поэтому этот вариант тоже отметила) и готовые CMS. Завершу перевод на Yii самого большого своего сайта, и начну изучать ZF — для начала с целью подключения отдельных модулей к Yii.
                                                                                                            • +3
                                                                                                              На работе — «голый» PHP, без всяких фреймворков. Да что там PHP, jQuery даже не используется нигде, так как проекты очень древние, а в большой фирме очень сложно ввести инновации какие-либо.
                                                                                                              На подработке использую: обычно Joomla (так как веб-студия, с которой работаю, предочла иммено ее, даже для сайтов с 5 страницами :( ) и Opencart для магазинов.
                                                                                                              Для своих проектов хочу YII ипользовать, очень уж понравился.
                                                                                                              • 0
                                                                                                                Если разработка коммерческая, то в основном CMS, т. к. это ощутимо ускоряет процесс, да и админский пользовательский интерфейс в CMS как правило целиком готов.
                                                                                                                Если для себя, то либо самописный фреймворк, либо вообще без фреймворка. Хоть времени на разработку уйдёт больше, работать оно будет на порядок быстрей. Да и с точки зрения безопасности такой подход мне нравится больше.
                                                                                                                • +2
                                                                                                                  Не то, чтобы это чистой воды фреймворк, но платформа неплохая — использую MODx. Для совсем простеньких сайтов есть свое легковесное рукоделие.
                                                                                                                  • +2
                                                                                                                    Согласен, MODX неплохой CMF и в последнее время активно развивается. Тоже его пользую.
                                                                                                                    • 0
                                                                                                                      Очень люблю modx. Пока в основном использую evolution, но потихоньку начал осваивать и revolution.
                                                                                                                      • 0
                                                                                                                        Сейчас начинаю проект по переводу на русский документации. В частности их rtfm. Если будет желание — сможете помочь. Революшн реально крут.
                                                                                                                        • 0
                                                                                                                          Желание есть! Пишите, где и когда.
                                                                                                                    • 0
                                                                                                                      Я использую Drupal и некий Spiral, мало кому известный :)
                                                                                                                      • +6
                                                                                                                        Yii + старые проекты на Zend'е. Отметил только Yii. Активный участник русскоязычного сообщества Yii.
                                                                                                                        • +14
                                                                                                                          Вот минусуйте меня, но не понимаю я тех людей которые не используют готовый фрейморк, а пишут свой. Работаю я с проектом на самописном фреймворке, хм по меньшей мере это убогое подобие фреймворка, которое кое как работает. Ну вот что такого в вашем самописном, чего не умеет ZF, CakePHP, Symfony и так далее? Вы в состоянии написать по нему разборчивую документацию с примерами и пояснениями? Как насчёт всяких там исправлений в безопасности и прочем? Сколько строк кода вы покрыли тестами? Сколько плагинов и сторонних библиотек интегрируются в ваш продукт? Сколько человек кроме Вас самого в состоянии, что то пояснить и дать разборчивый ответ? Всё равно наступит момент, когда станет ясно что самописный фреймворк больше не справляется с поставленными задачами.
                                                                                                                          • +2
                                                                                                                            >Ну вот что такого в вашем самописном, чего не умеет ZF, CakePHP, Symfony и так далее?

                                                                                                                            Частая причина — они умеют слишком много, мне столько не нужно и никто кроме меня этот код не увидит, а с фреймворком неизбежно будет оверхид и надо тратить время на изучение, а результат нужен вчера. А когда в ТЗ появляются новые фичи, которые свой фреймворк пока не умеет, проще уже реализовать её у себя, чем переводить проект на фреймворк, который уже давно умеет, поскольку это потребует переработки чуть более чем полностью даже при приличной архитектуре, не говоря о спагетти.
                                                                                                                            • +2
                                                                                                                              Да бросьте, полно легковесных фреймворков. Потом например в том же ZF и СakePHP есть возможность отключить не нужные компоненты.
                                                                                                                              > мне столько не нужно и никто кроме меня этот код не увидит
                                                                                                                              Парень который писал до меня этот проект, тоже наверное так думал
                                                                                                                              > А когда в ТЗ появляются новые фичи, которые свой фреймворк пока не умеет, проще уже реализовать её у себя
                                                                                                                              Хм то есть если сначала взять ZF, CakePHP, Symfony и так далее, то нужно только «подключить» понадобившийся функционал.
                                                                                                                              • 0
                                                                                                                                Меня уже несколько лет в пользе популярных фреймворков убеждать не надо :) Понял на практике, что пускай лучше будет неиспользуемая пока функциольность, чем потом писать её с нуля, вместо того, чтобы «поставить галочку».

                                                                                                                                Исключения, пожалуй, ситуации когда ресурсоемкость кода важнее его трудоемкости и универсальности, гибкости и прочей поддержки, то есть либо хайлоад проекты, где важна каждая микросекунда (но тут целесообразность использование PHP под вопросом), либо одноразовая работа в условиях крайне ограниченных и не контролируемых ресурсов (бесплатные хостинги, например).

                                                                                                                                Есть ещё вариант, когда использование популярных open source фреймворков/библиотек по каким-то причинам недопустимо или нежелательно. NIH и всё такое. Некоторые заказчики/работодатели настаивают на том, чтобы все права на код принадлежали им. И что уж греха таить, иногда они начинают настаивать на этом после парочки вопросов от исполнителя, заданных с целью увеличения трудоемкости, а значит и бюджета.
                                                                                                                            • 0
                                                                                                                              Ну вот что такого в вашем самописном, чего не умеет ZF, CakePHP, Symfony и так далее?

                                                                                                                              Они не всегда умеют быть достаточно простыми, и не всегда умеют быть совместимыми от версии к версии, а так же хуже заточены под конкретные задачи.

                                                                                                                              Со вторым понятно, последнее очевидно, а по поводу первого есть простой критерий. Если на фреймворке, его правильными и штатными средствами, какая-то задача выполняется более долго и решение выглядит более объемным чем на чистом пхп, то это как говорится «оверкилл» по сложности. Немного неточный пример, но очень хороший и показательный если посмотреть на него достаточно абстрактно был тут habrahabr.ru/blogs/programming/113128/
                                                                                                                              • +1
                                                                                                                                > Они не всегда умеют быть достаточно простыми
                                                                                                                                смотря какой критерий простоты. CakePHP «проще» ZF, Kohana «проще» Symfony и так далее. Yii в обще простенький.
                                                                                                                                > не всегда умеют быть совместимыми от версии к версии
                                                                                                                                всегда есть migration guide, хм ну некоторые версии php «несовместимы» deprecated функции и всё такое
                                                                                                                                > а так же хуже заточены под конкретные задачи.
                                                                                                                                Так это же фреймворк — ИНСТРУМЕНТ, а не РЕШЕНИЕ. В том то и дело, что мы с вами должны взять этот инструмент и заточить его под конкретные задачи, для этого они и разрабатывались.
                                                                                                                                • +1
                                                                                                                                  >В том то и дело, что мы с вами должны взять этот инструмент и заточить его под конкретные задачи, для этого они и разрабатывались.

                                                                                                                                  Наверное имелось в виду, что заточка может обойтись дороже изготовления своего инструмента.
                                                                                                                                  • 0
                                                                                                                                    я могу вам возразить, что изготовление своего инструмента с нуля и изготовление на основе каркаса ( фреймворка) будет дороже. Но кажется это уже попахивает холиваром :)
                                                                                                                                    • 0
                                                                                                                                      Если речь о построении одного сайта — Вы однозначно и 100% правы, лучше использовать распространённый фреймворк, чем писать свой велосипед.

                                                                                                                                      Но когда появляется много сайтов, встает необходимость поддерживать старых клиентов, нужен слегка разный функционал и единая среда разработки, то приходишь к тому, что у тебя 50 сайтов на 10 разных фреймворках в 5 разных версиях, с кучей хаков и несовместимых доработок. И этот зоопарк просто убивает время и не дает возможности качественной поддержки.

                                                                                                                                      Если же есть свой фреймворк, то все эти проблемы уходят. Простота его — первого сорта, нужный круг задач он решает, проблемы с обновлением нет. А если еще и на документацию время есть, то и других разработчиков несложно подключать.
                                                                                                                              • +4
                                                                                                                                Вот минусуйте меня, но не понимаю я тех людей которые не используют готовый фрейморк, а пишут свой…


                                                                                                                                Минусовать не собираюсь, но предлагаю взглянуть на проблему с другой стороны. Было бы такое многообразие фреймворков (причём у каждого со своими плюшками, каждый новый ещё красивее и лучше) если бы не создатели велосипедов, те которые пишут свои фреймворки? Symfony, Yii и прочия были не всегда, просто появились люди, которых не устроили существующие фреймворки. И они написали свои. У них получилось лучше (или им повезло).

                                                                                                                                Причины у людей использующих самопальные фреймворки могут быть совершенно различны:

                                                                                                                                1) нежелание/отсутствие времени разбираться в готовых фреймворках.

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

                                                                                                                                3) «Собственнические» взгляды:
                                                                                                                                — это написал я и я полностью понимаю происходящее и полностью представляю систему!
                                                                                                                                — стандартные фреймворки имеют кучу багов, а я пишу код лучше!
                                                                                                                                — стандартные фреймворки уязвимы!
                                                                                                                                и т.п.

                                                                                                                                Может что-то ещё.

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

                                                                                                                                Вспомните развитие многих громких проектов. Сколько гляжу, многие начинались с идеи «хочу свой лунапарк, с блекджеком и шлюхами!» и авторы садились писать их. А вокруг все твердили: «ну нафига тебе этот велосипед, ведь есть же обычная и простая телега. На ней и в соседнюю деревню можно съездить, и навоз привезти! А твой велосипед это фигня, да и непонятно, куда тут лошадь запрягать»

                                                                                                                                Как-то так.
                                                                                                                                • +2
                                                                                                                                  В чём то вы может и правы, но всегда тяжело понять человека находящегося по ту сторону силы )
                                                                                                                                  • +2
                                                                                                                                    > нежелание/отсутствие времени разбираться в готовых фреймворках

                                                                                                                                    Ну и глупость!
                                                                                                                                    • +2
                                                                                                                                      Я когда-то тоже писал свой фреймворк с нуля. Написал полКоханы и потом образумелся)
                                                                                                                                      • +1
                                                                                                                                        главное перерасти ) и вовремя остановиться
                                                                                                                                  • +6
                                                                                                                                    Yii, ибо гибкий, отличное сообщество и впитал в себя много положительного от различных фреймворков.
                                                                                                                                    • +1
                                                                                                                                      Используется самописный, но не потому что есть желание изобретать велосипед, а потому что
                                                                                                                                      1) Поддерживаются даже очень старые клиенты (в смысле люди), некоторые с сайтами сделанными еще на 1 версии 5 летней давности. Обновить свой фреймворк намного проще, чем чужой.
                                                                                                                                      2) Поддержка намного упрощается, т.к. есть возможность использовать везде один и тот же фреймворк, дорабатывая его по мере надобности. А иначе пришлось бы использовать разные и постоянно тратить время что бы быть в курсе событий всех фреймворков.
                                                                                                                                      3) Легко вносить свои изменения, четко зная что со следующей версией они не станут несовместимыми в чем-то или будут конфликтовать. И что эти изменения именно будут постоянно включены во фреймворк, не надо просить авторов фреймворка их включить с риском нарваться на отказ.
                                                                                                                                      4) Есть своя любимая ЦА клиентов с определёнными типами сайтов, с которыми идет работа. Фреймворк со временем стал весьма заточен под них, нет ничего лишнего, есть почти все необходимое, а то чего нет — просто добавляется.
                                                                                                                                      • 0
                                                                                                                                        Конечно понятен кайф от написания чего-то своего и использования его :)

                                                                                                                                        2 — не согласен
                                                                                                                                        3 — до тех пор, пока вы его развиваете.

                                                                                                                                        Представим, что вы работаете по найму с фреймворком скажем AAA, и изредка поддерживаете те сайты. Вы постепенно забудете свой, это неизбежно. Вы увидите что обновлять его все сложнее и сложнее, что вы пишите велосипед, т.е. в итоге — больше работы чем использовать распространненый фреймворк — мое мнение.

                                                                                                                                        • 0
                                                                                                                                          Конечно понятен кайф от написания чего-то своего и использования его :)
                                                                                                                                          Кайф был первые пару лет:) Сейчас просто прагматичный подход.

                                                                                                                                          3 — до тех пор, пока вы его развиваете.
                                                                                                                                          Представим, что вы работаете по найму с фреймворком скажем AAA, и изредка поддерживаете те сайты. Вы постепенно забудете свой
                                                                                                                                          Не вполне понятна аргументация. Речь в посте на который Вы отвечали шла о том, что никакой фреймворк «ААА» и даже «БББ» не используется, а развивается свой. Вы же контр-аргументируете тем, что на самом деле-то используется фреймворк «ААА», а свой забывается.
                                                                                                                                      • +3
                                                                                                                                        Yii для среднекрупного
                                                                                                                                        А мелкий бложек или визитку можно и на голом php собрать.
                                                                                                                                        • +4
                                                                                                                                          Удивлен какое кол-во людей не используют фреймворки, или что хуже — используют свои

                                                                                                                                          Для коммерческой разработки однозначно стоит использовать самые распространенные фреймворки, или, в случае front-end сайтов — движки типа Drupal.

                                                                                                                                          Поддержка проекта на custom framework — это очень трудно и не очень полезно :( как раз этим и занимаемся щас.

                                                                                                                                           
                                                                                                                                          Мой Test Case: ухожу на другую работу. текущий проект на custom framework, проект был начат аусторсом в другой конторе.

                                                                                                                                          1. Мой опыт поддержки этого framework практически можно выкинуть в корзину. Был бы Zend Framework, я бы получил полезный опыт и нашел работу с выше оплатой, т.к. работодатели в основном выбирают ZF.

                                                                                                                                          2. Проблемы и баги этого framework нигде не описаны. Практик реализации той или иной задачи нет. Гугл не помощник.

                                                                                                                                          3. Человек, что придет заменять меня, этот framework конечно не знает и знать не может, потратит кучу времени как сделать то и это.

                                                                                                                                          • +1
                                                                                                                                            Удивлен какое кол-во людей не используют фреймворки, или что хуже — используют свои
                                                                                                                                            Я подозревал :-) Но для проверки решил запостить этот опрос.
                                                                                                                                            По пунктам полностью согласен с вами.
                                                                                                                                          • –3
                                                                                                                                            Использую свой собственный фреймворк, в основном из-за своей лени и нежеления что-либо ещё изучать. Постепенно переползаю на grails с php вообще.
                                                                                                                                            • +2
                                                                                                                                              Конечно же, самый правильный фрэймворк от создателей PHP — Zend Framework :)
                                                                                                                                              Плюс самописные компоненты на его основе.
                                                                                                                                              • 0
                                                                                                                                                «самый правильный» для определенного перечна задач. далеко не всегда можно удовлетворится чужим фреймворком ввиду того, что он может не поддерживать необходимый функционал на уровне архитектуры)
                                                                                                                                                • +1
                                                                                                                                                  Там смайлик в конце :)

                                                                                                                                                  Не подскажете, для каких задач не подходит ZF?
                                                                                                                                                  • –1
                                                                                                                                                    в моем комментарии ниже писал небольшой перечень задач, которые приходилось решать — после оценки того, что надо реализовывать решили писать свою систему, а не использовать готовые)
                                                                                                                                                    • –3
                                                                                                                                                      Хочу добавить — решить, может, и можно. но вопрос в том насколько это будет эффективно сделано. в нашем случае мы посчитали, что эффективнее будет сделать свое.
                                                                                                                                                  • +1
                                                                                                                                                    На работе написали фреймворк с нуля. так как не нашли ничего подходящего для наших целей — штамповка большого кол-ва сайтов — информационных порталов (на данный момент уже 17 штук, будет больше в разы), создавать сайтам группы — у каждой группы идет наследие настроек, шаблонов, триггеров у главного сайта (а она наследует базовые настройки системы в общем) в группе, так же можно для каждого сайта индивидуально создать свой шаблон для любого модуля, изменить любой конфиг и прочее.
                                                                                                                                                    работа с сайтами (админ. работа над контентом) происходит централизовано на одном хостинге, потом сайты кешируются целиком (с добавлением минимальной динамики, вроде комментариев, поиска, контакт формы — все запросы идут нацентральный хостинг и он возвращает ответ на сайт, а там происходит вывод информации) и заливаются уже на свои хостинги.

                                                                                                                                                    еще очень много инфраструктурных нюансов, которые необходимо было решать и поэтому пришлось писать систему с нуля)
                                                                                                                                                    • +1
                                                                                                                                                      Я практически все веб-проекты делаю на TYPO3, ипользую именно его. Но планирую в ближайшем будущем попробовать Yii: очень его хвалил один человек, мнение которого я уважаю.
                                                                                                                                                      • 0
                                                                                                                                                        «делаю» – в данном случае имеется ввиду как раз создание новых функциональных модулей, а не простое клепание сайтов.
                                                                                                                                                      • 0
                                                                                                                                                        Kohana вполне устраивает
                                                                                                                                                        • 0
                                                                                                                                                          Использовали CakePHP раньше. Когда стала задача разнести ГУИ и бизнес-логику с БД на разные серверы, то ГУИ написали на CodeIgnitor (выбрали потому что слышали, что он самый быстрый и довольно простой), а все остальное уже самописное.
                                                                                                                                                          • 0
                                                                                                                                                            Drupal использую
                                                                                                                                                            • +3
                                                                                                                                                              Начал с Drupal, потом шли Wordpress, Joomla и вернулся к н