Comments 149
UFO just landed and posted this here
На вкус и цвет… Мне вот не нравится её ORM из коробки и встроенная ACL-система. На проектах, где использовал кохану пришлось эти куски переписывать под себя, хотя в остальном она неплоха.
По работе использую ZF1, Smarty3 и PgSQL а для себя простенький самописный MVC-фреймворк без шаблонизатора с MySQL.
По работе использую ZF1, Smarty3 и PgSQL а для себя простенький самописный MVC-фреймворк без шаблонизатора с MySQL.
UFO just landed and posted this here
Не секрет. Выбор «многие ко многим». Да и вообще, мне ORM неудобно. Голый SQL с биндами мне более по душе.
ORM на первый взгляд очень красивая и удобная штука. Но когда начинаешь работать с ORM в сложных проектах, она зачастую очень сильно снижает производительность. Для борьбы с этим приходится делать кучу ручной кастомизаций или костылей. А в итоге, зачастую оказывается что проще было изначально писать все на голом SQL, чем пытаться заставить ORM работать с приемлемой производительностью.
Ни кто и не запрещает вам ORM не использовать ведь, просто выключите модуль. Есть еще вполне нормальный query builder
Попробую вставить и свои 5 копеек. Как по мне ORM в первую очередь это удобный быстрый инструмент для CRUD. Для админки или относительно простого запроса это сэкономит кучи нервов, сил и времени. Но когда речь идет о сложных запросах или выборке больших объемов данных нужно 10 раз подумать выгодно ли использовать ORM. Во первых потребляемый объем памяти. Объекты порой занимают в разы больше памяти по сравнению если бы вы использовали чистые массивы (на одном высоко нагруженном проекте после ухода с ORM потребление памяти одного селекта к примеру вместо 90мб уменьшилось до 5мб ). Второе время выполнения и потрачено время на адаптацию запроса для ORM (пока найдешь по документации как сделать какой нибудь CONCAT('1, '2', '3')). Буду капитаном если скажу что серебряной пули не бывает. Но каждый уважающий себя разработчик должен точно знать когда и какой инструмент будет эффективнее в конкретном случае.
P.S. Пусть на меня не обижаются yii-сты, но там ORM… как сказать помягче… есть намного лучше варианты.
P.P.S Чуток промахнулся веткой, извините)
P.S. Пусть на меня не обижаются yii-сты, но там ORM… как сказать помягче… есть намного лучше варианты.
P.P.S Чуток промахнулся веткой, извините)
Кохане тяжело попасть в «самые стабильные» (каждый билд ломает совместимость) и в «самые развивающиеся» (скоро 3.3 перестанет поддерживаться, а 3.4 даже не альфа, вроде). Имхо, самый стабильный — yii/codeigniter, самый развивающийся — laravel, мой выбор — kohana.
UFO just landed and posted this here
Потому, что удобно. Я даже не знаю как это объяснить, если честно (. Наверное — минималистичность. Минимум лишнего, минимум сложностей, минимум требований. Легко выкинуть или заменить любой класс ядра, не мешая самому приложению (например, заменить mysql в приложении на… что угодно. или классы Exception_* на свои и все приложения/ядро будут использовать новый функционал). Нечто подобное испытываю с phalcon, но он еще сырой (.
По поводу ORM — ничего не скажу. Вообще. Не использую ни под каким соусом.
По поводу ORM — ничего не скажу. Вообще. Не использую ни под каким соусом.
Я тоже использую Kohana. Стабильности в ней никакой, фреймворк почти заброшен (3.3 использует устаревшее API и вызывает E_DEPRECATED на новом PHP, 3.4 есть только на Github в сыром виде), для pull request'ов принята особая процедура через багтрекер Kohana, большинство модулей необходимо не только обновлять под новый PHP и библиотеки, но ещё и допиливать.
Но. Для меня все недостатки нивелируются структурой и архитектурой фреймворка. Вместе с Kostache получается очень чёткая и жёсткая система: Controller — Model — View — Template. Когда для логики преставления есть отдельный класс, в котором даже циклы должны вычисляться. Все реюзабельные блоки, которые в других фреймворках как только ни называются (паршиалы, кусочки, фрагменты) — это всего лишь View+Template, куда кидаются данные свыше, мало или много ли там логики. При этом фреймворк достаточно производительный и простой.
Но. Для меня все недостатки нивелируются структурой и архитектурой фреймворка. Вместе с Kostache получается очень чёткая и жёсткая система: Controller — Model — View — Template. Когда для логики преставления есть отдельный класс, в котором даже циклы должны вычисляться. Все реюзабельные блоки, которые в других фреймворках как только ни называются (паршиалы, кусочки, фрагменты) — это всего лишь View+Template, куда кидаются данные свыше, мало или много ли там логики. При этом фреймворк достаточно производительный и простой.
Странное голосование, если честно. Надо результаты первых голосований смотреть относительно «вашего выбора».
Зря вы silex и symfony разделили только, в общем то там, что авторы, что кодовая база одна и та же.
Как минимум по первым 2м опросам они должны быть вместе, потому что одни компоненты в основе.
Как минимум по первым 2м опросам они должны быть вместе, потому что одни компоненты в основе.
Что за форсирование yii?
[зануда] раз уж вы юзаете интернетовский сленг (forcить), то не форсирование, а форсинг [/зануда]
Если уж на то пошло, то возможно WaveCut имел в виду, что много народу бросилось изучать данный фреймворк и сравнил это с форсированием реки.
о_О
о_О
Для интереса стоило добавить пункт «нативный PHP/собственный framework», чтобы охватить всю аудиторию.
Думаю, можно смотреть на воздержавшихся
Я нажал «Воздержаться», т.к. не использую пхп вообще, но узнать результаты интересно.
А я нажал воздержаться, т.к. вообще не понимаю как я и большинство проголосовавших могут знать ответы на вопросы а-ля «Самый развивающийся фреймворк 2013», когда пробовали то из них 3-4 от силы. А уж слежу я за развитием только одного фреймворка.
Я с полгода назад проводил опрос по PHP-фреймворкам habrahabr.ru/post/183290/. 5000 проголосовало, вполне репрезентативно.
Нет onPHP в списке тех, которые в этом году использовал.
Хотя в будущем хотел бы попробовать поработать в полной мере с Symfony
Хотя в будущем хотел бы попробовать поработать в полной мере с Symfony
Самый стабильный можно определить без голосования — достаточно посмотреть на трекеры проектов.
Я вот не знаю сколько там багов в каком фреймворке нашли и насколько они критичны, и как быстро их закрыли.
То же можно сказать и про скорость развития. Количество релизов, коммитов, расширений можно посчитать.
Поэтому и воздержался.
И остается только собственный субъективный выбор.
Я вот работаю с Yii — но только по привычке, мне его хватает почти что полностью.
Посмотрел на другие — ну все там, грубо говоря, так же. И зачем мне переходить на них?
Хотя возможно они и быстрее, и где-то (в тех местах, которые я не использую) удобнее.
Я вот не знаю сколько там багов в каком фреймворке нашли и насколько они критичны, и как быстро их закрыли.
То же можно сказать и про скорость развития. Количество релизов, коммитов, расширений можно посчитать.
Поэтому и воздержался.
И остается только собственный субъективный выбор.
Я вот работаю с Yii — но только по привычке, мне его хватает почти что полностью.
Посмотрел на другие — ну все там, грубо говоря, так же. И зачем мне переходить на них?
Хотя возможно они и быстрее, и где-то (в тех местах, которые я не использую) удобнее.
Холивар 2013!
UFO just landed and posted this here
Тоже мнение: какое развитие у Yii? Это самый медленно развивающийся FW в индустрии, по-моему.
UFO just landed and posted this here
надо еще смотреть на количество и качество расширений.
Скорее всего многие, как и я, имели в виду yii2 — самую активно развивающуюся версию этого замечательного фреймворка.
ее пишут больше 2-х лет, и по своей сути она не сильно от первой версии ушла. У yii не такое большое количество контрибьютеров как у symfony к примеру. Более того, использовать готовые решения (как например поступили ребята из laravel) они не хотят ибо большая часть готовых решений не соответствует философии фреймворка и повышает порог вхождения.
Так ведь развивающийся, а не развившийся. Вторая версия пишется вовсю, вот и развитие.
Подскажите, что же в нем такого нового?
Информации о нём больше :)
еще одна бессмысленная статистика… Как пользователи не знакомые со всеми перечисленными фреймворками могут оценить стабильность? или развитие? В любом случае голосовать будут за то что знают/используют. Смысла в такой статистике нет.
Стабильность можно оценить покрытием кода тестами, развитие — количеством пул-реквестов и коммитов.
Лучше бы проектики типа blogmvc.com развивали, толку больше чем от таких статистик…
Как по мне, то самый стабильный это Symfony 1.4, с которым сейчас работаю :(
Хотелось бы посмотреть в глаза людям выбравшим phalcon и спросить — это, серьезно, «ваш выбор»? Потому, как уже больше полугода с ним боремся и всеравно не перестает удивлять своими оригиналными решениями.
А что с ним не так? Мне идея понравилась, но использовать так и не удалось.
идея мне тоже нравится, мне не нравится реализация и выбор заведомо не популярных решений.
Например, в пагинаторе вместо обертывания, используется модификация запроса, из-за чего он работает правильно только на тривиальных запросах. ORM кеширует не только результаты выбоки из бд, но и их отсутствие. И т.д.
Вцелом фреймверк ооочень сырой, много чего приходиться делать через костыли.
Например, в пагинаторе вместо обертывания, используется модификация запроса, из-за чего он работает правильно только на тривиальных запросах. ORM кеширует не только результаты выбоки из бд, но и их отсутствие. И т.д.
Вцелом фреймверк ооочень сырой, много чего приходиться делать через костыли.
ORM кеширует не только результаты выбоки из бд, но и их отсутствие.
А в чем проблема? Пустой список вполне нормальный и довольно частый результат, почему он не должен кэшироваться?
вот где я писал про список?
перед тем как добавить запись в бд нужно проверить, что ее там нет. А так как орм кеширует все подрят, это выливается в дубликаты.
перед тем как добавить запись в бд нужно проверить, что ее там нет. А так как орм кеширует все подрят, это выливается в дубликаты.
Плохая инвалидация.
перед тем как добавить запись в бд нужно проверить, что ее там нет
При таком подходе вы получите race condition.
Поставьте уникальный индекс и обрабатывайте исключение, возникающее при вставке дубликата.
во-первых, задача зачастую не просто добавить, а и обновить существующие.
во-вторых, ексепшены это всетаки исключительное событие, а индексы это внутренний механизм оптимизации и контроля целосности бд, так сказать, последний рубеж.
втретьих, race condition возникает только если есть несколько потоков.
вчетвертых, почему вы меня программировать учите, вы ведь кода моего не видели?
во-вторых, ексепшены это всетаки исключительное событие, а индексы это внутренний механизм оптимизации и контроля целосности бд, так сказать, последний рубеж.
втретьих, race condition возникает только если есть несколько потоков.
вчетвертых, почему вы меня программировать учите, вы ведь кода моего не видели?
задача зачастую не просто добавить, а и обновить существующие.
On duplicate key update Вам в помощь.
ексепшены это всетаки исключительное событие
Исключения и ошибки — это одного поля ягоды. БД не бросит исключение — БД вернет ошибку, а бросит исключение Ваш код. Например, mysql_* не бросает исключений, а PDO бросает — суть не меняется.
а индексы это внутренний механизм оптимизации и контроля целосности бд, так сказать, последний рубеж.
Предотвратить вставку уже существующих данных — это и есть контроль целостности.
race condition возникает только если есть несколько потоков
Вы правы. Опять же, БД предоставляет Вам возможность избежать гонки.
почему вы меня программировать учите, вы ведь кода моего не видели?
1. Я вас не учу.
2. Комментирование создано, как раз, для обсуждения.
3. На мой взгляд, Вы описали «плохие» подходы. И кто-то может научиться у Вас «плохому».
4. Вы можете оказаться правы и, в таком случае, чему-то научусь я.
какой смысл в красном без короткого? это две абсолютно разные вещи
Having без group by — не имеет смысла, и разрешен, если я не ошибаюсь, только в MySQL — в остальных БД Вы получите ошибку.
так, уважаемый, вы вобще знакомы с phalcon?
Мне приятно знать, что есть люди которые хотят помочь другим, а не только раздают плюсы и минусы, но как решить задачу я и сам знаю. Мы тут обсуждаем конкретную орм и ее релизацию. Поэтому ваши коментарии, звучат как «ходи конем» при игре в преферанс.
Мне приятно знать, что есть люди которые хотят помочь другим, а не только раздают плюсы и минусы, но как решить задачу я и сам знаю. Мы тут обсуждаем конкретную орм и ее релизацию. Поэтому ваши коментарии, звучат как «ходи конем» при игре в преферанс.
> On duplicate key update Вам в помощь.
ну если вы приведете способ как это использовать в рамках фальконовской орм, то это можно будет считать помощью, а так это непонятно что…
>Исключения и ошибки — это одного поля ягоды. БД не бросит исключение — БД вернет ошибку, а бросит исключение Ваш код. Например, mysql_* не бросает исключений, а PDO бросает — суть не меняется.
вы, реально, сравниваете мягкое и теплое. Что там на уровне бд просходит, при описании бизнес логики, мне не особо важно.
В коде ошибки и ексепшены — это РАЗНОГО ПОЛЯ ЯГОДЫ. Ошибки — это уровень бизнес логики(орм говорит что значение в поле недопистимо), эксепшены — ошибки более низкого уровня(транзакция не прошла). Если есть возможность избежать ексепшена, то лучше это сделать, т.к. вещать бизнес логику на обработку ексепшена, не очень хорошо, всетаки их задумывали, чтоб дать возможность программисту сохранить логи и завершить приложение.
>1. Я вас не учу.
2. Комментирование создано, как раз, для обсуждения.
3. На мой взгляд, Вы описали «плохие» подходы. И кто-то может научиться у Вас «плохому».
4. Вы можете оказаться правы и, в таком случае, чему-то научусь я.
моя притензия была не к коментарию, а к формулировке.
Если бы вы разбавили ваше предложение фразами типа:
>Having без group by — не имеет смысла, и разрешен, если я не ошибаюсь, только в MySQL — в остальных БД Вы получите ошибку.
возможно это поддержывается не во всех бд. Но это поддерживают Mysql и Postgresql, а это самые популярные бесплатные бд.
ну если вы приведете способ как это использовать в рамках фальконовской орм, то это можно будет считать помощью, а так это непонятно что…
>Исключения и ошибки — это одного поля ягоды. БД не бросит исключение — БД вернет ошибку, а бросит исключение Ваш код. Например, mysql_* не бросает исключений, а PDO бросает — суть не меняется.
вы, реально, сравниваете мягкое и теплое. Что там на уровне бд просходит, при описании бизнес логики, мне не особо важно.
В коде ошибки и ексепшены — это РАЗНОГО ПОЛЯ ЯГОДЫ. Ошибки — это уровень бизнес логики(орм говорит что значение в поле недопистимо), эксепшены — ошибки более низкого уровня(транзакция не прошла). Если есть возможность избежать ексепшена, то лучше это сделать, т.к. вещать бизнес логику на обработку ексепшена, не очень хорошо, всетаки их задумывали, чтоб дать возможность программисту сохранить логи и завершить приложение.
>1. Я вас не учу.
2. Комментирование создано, как раз, для обсуждения.
3. На мой взгляд, Вы описали «плохие» подходы. И кто-то может научиться у Вас «плохому».
4. Вы можете оказаться правы и, в таком случае, чему-то научусь я.
моя притензия была не к коментарию, а к формулировке.
Поставьте уникальный индекс и обрабатывайте исключение, возникающее при вставке дубликата.
Если бы вы разбавили ваше предложение фразами типа:
возможно вам поможет,
попробуйте,
может быть вас устроит данное решение.
>Having без group by — не имеет смысла, и разрешен, если я не ошибаюсь, только в MySQL — в остальных БД Вы получите ошибку.
возможно это поддержывается не во всех бд. Но это поддерживают Mysql и Postgresql, а это самые популярные бесплатные бд.
Работаем с Phalcon больше года, проблем и сожалений о выборе нет, запущено несколько боевых проектов с разного рода нагрузкой и сложностью. Готов ответить на любые вопросы и оказать поддержку в специальной Phalcon-группе вконтакте: vk.com/phalconphp
неужеле и ORM и шаблонизатор используете и никаких проблем?
Volt стали использовать лишь последние полгода, проблем нет. С ORM вообще с самого начала нормально всё, пару раз научишь ся формировать правильно отношения и запросы — дальше уже совсем легко.
>Volt стали использовать лишь последние полгода, проблем нет.
compileAlways если включить, то приложение падает с segmentation fail.
A если шаблон не найден, то просто падает без каких либо ошибок, как при exit(0).
>С ORM вообще с самого начала нормально всё, пару раз научишь ся формировать правильно отношения и запросы — дальше уже совсем легко.
когда делаеш джоины нужно вставлять пробелы
одну модель можно приджоинить только один раз
отсутствие такой штуки как Zend\Db\Expr, как следстие все, что не понимет орм, вызывает ексепшн.
having работает только если задан group
валидация в моделях не отключаема и рекурсивна, если в какой-то связи есть ошибка, данные не сохранятся.
вот, из того, что сразу вспомнилось.
compileAlways если включить, то приложение падает с segmentation fail.
A если шаблон не найден, то просто падает без каких либо ошибок, как при exit(0).
>С ORM вообще с самого начала нормально всё, пару раз научишь ся формировать правильно отношения и запросы — дальше уже совсем легко.
когда делаеш джоины нужно вставлять пробелы
одну модель можно приджоинить только один раз
отсутствие такой штуки как Zend\Db\Expr, как следстие все, что не понимет орм, вызывает ексепшн.
having работает только если задан group
валидация в моделях не отключаема и рекурсивна, если в какой-то связи есть ошибка, данные не сохранятся.
вот, из того, что сразу вспомнилось.
Issue для всех описанных проблем с описанием созданы?
>Issue для всех описанных проблем с описанием созданы?
Очень неожиданый вопрос от человека, который больше года работает с данным кодом.
Вот еще вспомнил, что по-умолчанию орм делает full update, на каждый вызов метода save делается апдейт всех полей в независимости от того были ли изменения.
Можно включить dynamic update но он кривой. При создании модели данные сохраняются в snapshotData и при сейве делается ипдаейт на измененные поля, но snapshotData инициализируется не всегда и кроме того snapshotData не обновляется после сейва, тоесть последующие сейвы работают не правильно.
Очень неожиданый вопрос от человека, который больше года работает с данным кодом.
Вот еще вспомнил, что по-умолчанию орм делает full update, на каждый вызов метода save делается апдейт всех полей в независимости от того были ли изменения.
Можно включить dynamic update но он кривой. При создании модели данные сохраняются в snapshotData и при сейве делается ипдаейт на измененные поля, но snapshotData инициализируется не всегда и кроме того snapshotData не обновляется после сейва, тоесть последующие сейвы работают не правильно.
Вопрос про issue был к тому, что их довольно оперативно исправляют, про compileAlways помню проблема была несколько месяцев назад, но было исправлено. Остальные такие проблемы за время работы и вправду не попадались, так вот получилось.
ну значит к вам они более богосклонны, мне они оперативно предлагают костыли
github.com/phalcon/cphalcon/issues/1013
github.com/phalcon/cphalcon/issues/978
github.com/phalcon/cphalcon/issues/1013
github.com/phalcon/cphalcon/issues/978
having работает только если задан group
Какой смысл в having без group?
отсутствие такой штуки как Zend\Db\Expr, как следстие все, что не понимет орм, вызывает ексепшн
docs.phalconphp.com/en/latest/api/Phalcon_Db_RawValue.html
>This class allows to insert/update raw data without quoting or formating
есть подозрение, что QueryBuilder не схавает, но если схавает, то возьму свои слова назад.
есть подозрение, что QueryBuilder не схавает, но если схавает, то возьму свои слова назад.
как я и думал, queryBuilder'у фиолетово на этот RawValue
timestampdiff(HOUR, from_date,to_date)
Column 'HOUR' doesn't belong to any of the selected models (1)
одну модель можно приджоинить только один раз
ORLY
С использованием алиасов я лично джойнил одну и ту же модель многократно. Или имеется в виду невозможность иметь объекты одного типа в результате?
использование class_alias для джоинов это костыль, Или вы костыли приравниваете к функционалу фреймверка?
За два месяца практически перевели на Фалкон 1 большой проект и написали проект чуть поменьше. Да, были трудности, но в целом и скорость разработки и скорость работы радуют. Разработчики после первого зенда очень рады.
Плюс я один свой личный мини сайт перепиливаю с зенда на Фалкон. Единственное, к чему есть претензии — это механизм миграций. Тут пока приходится иметь костыли.
Плюс я один свой личный мини сайт перепиливаю с зенда на Фалкон. Единственное, к чему есть претензии — это механизм миграций. Тут пока приходится иметь костыли.
ок, Success Story засчитан.
Если не секрет, с какого фремверка переписывали? фалькон 1,2?
У меня после первого зенда и второй симфони, вызывает не однозначные чувства. Да, на нем можно быстро стартовать чтото, за счет очень простой MVC. Но баги лезут от куда их ждешь меньше всего. Небольшие ченджи оборачиваются костылями, которые каждый разработчик решает по своему, за отведенное время, врезультате проект обростает костылями со всех сторон.
Если не секрет, с какого фремверка переписывали? фалькон 1,2?
У меня после первого зенда и второй симфони, вызывает не однозначные чувства. Да, на нем можно быстро стартовать чтото, за счет очень простой MVC. Но баги лезут от куда их ждешь меньше всего. Небольшие ченджи оборачиваются костылями, которые каждый разработчик решает по своему, за отведенное время, врезультате проект обростает костылями со всех сторон.
Переписывали с первого зенда.
Особых багов сейчас не заметил. Пробовал Фалкон еще примерно на версии 0.6 — тогда да, было тяжело. Согласен — есть несколько неоднозначных штук (роутинг к примеру), но привыкнуть можно, а скорость и полнота фреймворка радуют.
А то, что проект обрастает костылями, так эта ситуация, в принципе, нормальная — периодический рефакторинг неизбежен при использовании любого фреймворка
Особых багов сейчас не заметил. Пробовал Фалкон еще примерно на версии 0.6 — тогда да, было тяжело. Согласен — есть несколько неоднозначных штук (роутинг к примеру), но привыкнуть можно, а скорость и полнота фреймворка радуют.
А то, что проект обрастает костылями, так эта ситуация, в принципе, нормальная — периодический рефакторинг неизбежен при использовании любого фреймворка
Вообще использую CodeIgniter, но результаты опроса подталкивают попробовать Yii, стоит ли тратить на него время?
Мой любимый Yii в лидерах. Это радует :)
Даешь ZF2!
Опросы отлично показывают кто на чем пишет, а не предмет опроса =)
И как минимум странно видеть Zend Framework 1 в опросе
И как минимум странно видеть Zend Framework 1 в опросе
Самый развивающийся фреймворк 2013
Самый стабильный — это CodeIgniter. Каким был в начале года, таким и остался.
плюсую KO3 и CI
Phalcon
Ребята, чем вам так нравится Yii?(указывайте какого рода проекты вы на нем делаете)
Нравится простотой, гибкостью, производительностью, лёгкостью в переопределении всего и вся. Отличное коммьюнити, прекрасная документация, приятный код. Мои проекты на Yii/Yii2 — новостные сайты, блоги, CRM, сервисы автоматизации. Так что область применения весьма обширна.
Приходилось работать с Yii, мне показалось что слишком много там накручено всего, из-за чего гибкость очень страдает.
там все слишком завязано на наследовании и на базовых классах… простенькими декораторами некоторый функционал по сути вообще не реализовать… хотя в коде самого фреймворка ( во всяком случае для ветки 1,1) тайп хинтинга нету, так что можно впихнуть и декоратор, но зачастую приходится из нижних уровней копипастить код.
Нравится всем. Делали на нём всё: сайты, блоги, CMS, CRM, тревел-сервисы, API для мобильников, логистику, магазины и т.д.
Что насчет виджетов? Я много раз видел что шаблоны для Yii вообще не содержат HTML кода, все делается через виджеты. Даже слышал, что требуются специальные верстальщики которые знакомы с Yii.
это такой же вид истерии как плагины для jquery, когда любой пук делается через плагин. Хотя я к примеру отказался и от идущего в комплекте менеджера асетов, написал свой (конкатенация и аглификация скриптов и стилей, сжатие изображений, препроцессинг less, и последующая компрессия в gzip для статической раздачи nginx-ом). Правда я еще и twig использую обычно… в последнем проекте даже от стандартного механизма маршрутизации отказался ибо он слишком примитивный и не дает без кастылей добавить префиксы с параметрами для урлов, заменил на symfony/routing.
Что насчет виджетов? Я много раз видел что шаблоны для Yii вообще не содержат HTML кода, все делается через виджеты. Даже слышал, что требуются специальные верстальщики которые знакомы с Yii.
Совать все в виджеты — сущее баловство. Yii ничего такого не требует.
Мой выбор это Yii — быстро, красиво, и на достойном уровне все.
Конечно, лучшее ООП в Symfony — но тормоза сводят красоту на нет.
Конечно, лучшее ООП в Symfony — но тормоза сводят красоту на нет.
Почему Джумлы нет? У нее вроде есть какой-то фреймворк
Так и у друпала и у битрикса есть. Но зачем?)
Я бы его выбрал :). Ну да, такой вот я мазохист, нравится она мне.
А там есть полноценный фремворк, подобный упомянутым в голосовании? Я просто не знаком с устройством этой CMS.
Только собирались выпускать, была новость некоторое время назад.
Есть. Подробнее тут
Yii можно было разделить на 1/2 (как Zend).
А популярность Zend Framework все падает и падает.
Легковесные и простые в освоении фреймворки вытесняют монстрообразные фреймворки.
Легковесные и простые в освоении фреймворки вытесняют монстрообразные фреймворки.
Symfony2 с вами не согласен. Всего то нужна удобная модульность системы.
Laravel основан на компонентах symfony, так же как и silex. Кучи cms-ок (в том числе Drupal) так же сейчас пишут на основе хотя бы HttpKernel и используют composer. Профит модульности в том что можно менять модули, добавлять свои, легко собирать фреймворки под свои нужды… не понятно почему минусуют.
Еще было бы интересно добавить в опрос, какие фичи фрейворков наиболее важны для разработчиков. Например ORM, генераторы форм, шаблонизаторы и т.п.
Выбор — Symfony 2. (Для мелких проектов — свой)
С Yii работал всего на 1 проекте — не понравился. А именно: стиль кода, логика, документация. Не понимаю, что в нем нашли. Ок, 2-3 года назад выбор был бы понятен, а сейчас — нет.
Интересно:
— Какие плюшки вы в нем нашли?
— Чем он лучше по сравнению с той же Симфони?
С Yii работал всего на 1 проекте — не понравился. А именно: стиль кода, логика, документация. Не понимаю, что в нем нашли. Ок, 2-3 года назад выбор был бы понятен, а сейчас — нет.
Интересно:
— Какие плюшки вы в нем нашли?
— Чем он лучше по сравнению с той же Симфони?
— Чем он лучше по сравнению с той же Симфони?Невысоким порогом вхождения?
Sf2 нужно изучить, прежде чем разработка на нём станет эффективнее разработки на других фреймворках. Периодически наблюдаю людей, которые решили освоить Symfony2 в процессе работы над коммерческим продуктом — потом они либо учатся на ошибках, либо плюются желчью, обвиняя фреймворк в своих неудачах.
Ну а я видел как люди не знающие yii год фигачили проекты и были довольны… Как по мне лучше заставить человека месяц поизучать инструмент, прежде чем использовать. И да, если уж на коммерческом проекте и изучать, то в команде должен быть кто-то кто уже знаком с фреймворком.
Ну а я видел как люди не знающие yii год фигачили проекты и были довольны…Кажется, я мысль не совсем уловил. Если все довольны — это ведь замечательно.
В краткосрочной перспективе может оказаться выгоднее разработать продукт подручными средствами, чем тратить время на создание лиги выдающихся джентльменов.
ключевое в вашей фразе — краткосрочная перспектива. Проекты развиваются, заказчики иногда присылают списки изменений… У меня сейчас на поддержке один проектик только остался на yii, который начинали еще на версии 1.0, к нему приложило руку с десяток разработчиков, и… скажем так… там такое раздолье для рефакторинга… Причем иногда такие перлы находятся. В итоге вроде бы и проект простой (интернет магазинчик со своей спецификой), но в итоге некоторые проблемы как раз таки изза ограничений фреймворка. (и да, во второй ветке часть этих ограничений уже пофиксили, специально смотрел).
90% Проектов можно написать без особых проблем как на любом из Фреймворков так и на ЦМС. Тут больше всего влияет 1 момент:
— На сколько хорошо знаешь инструмент на котором пишешь?
— На сколько хорошо знаешь инструмент на котором пишешь?
ну и еще стоимость поддержки решения, предсказуемый цикл разработки и поддержки самого фреймворка/cms, количество разработчиков которые «знают инструмент на котором пишут»… Для личных проектов разницы нету, но вот для коммерческих я сразу же использовать первое попавшееся/самое популярное решение не буду.
Tfw самый стабильный и самый развивающийся один и тот же. inb4 одно не отменяет другого — отменяет. Напоминает шаблон «молодая, быстро развивающаяся фирма.
Самый бесмысленный опрос 2013
Наверняка никто из тех кто голосовал — не в курсе аспектов развития всех перечисленных фреймворков, в итоге каждый ставит галочку напротив своего любимого фрэймворка.
Наверняка никто из тех кто голосовал — не в курсе аспектов развития всех перечисленных фреймворков, в итоге каждый ставит галочку напротив своего любимого фрэймворка.
мимо
Рад что PHPixie собирает голоса =)
Видимо мои статьи здесь принесли плоды ^__^
Видимо мои статьи здесь принесли плоды ^__^
Все 3 опроса можно было бы объединить в 1: «Ваш любимый фреймворк»
Надеялся на адекватность отвечающих, получил по морде реальностью.
Ну вот на хабре много хвалят Yii, но я взглянул на код примера и по мне это полный треш из мешанины статических методов в кривом code style. Symfony по мне на порядок продуманней и как ни странно проще, если разобраться всего в двух вещах: что такое контейнер объектов и как работать с событиями. Достаточно изучить 1 презентацию и ты будешь знать симфони на 90%. Для Symfony немеренно бандлов, это самый популярный php-репозиторий на гитхабе, это самое мощное комьюнити.
Но люди голосуют за то, что они используют, т. к. «тим лид сказал», «на хабре прочитал», «старые проекты на нем» и т. п.
Но люди голосуют за то, что они используют, т. к. «тим лид сказал», «на хабре прочитал», «старые проекты на нем» и т. п.
Посмотрите лучше код Yii2. Стиль там более человечный. Похож на тот же PSR-2.
Про комьюнити не согласен. Попробуйте задать глупый вопрос на форумах Symfony и Yii. На форумах Yii вам расскажут почему это неправильно и дадут наставления. На форумах Symfony расскажут какой вы никчёмный программист и что надо учить паттерны и контейнеры.
Про комьюнити не согласен. Попробуйте задать глупый вопрос на форумах Symfony и Yii. На форумах Yii вам расскажут почему это неправильно и дадут наставления. На форумах Symfony расскажут какой вы никчёмный программист и что надо учить паттерны и контейнеры.
UFO just landed and posted this here
Нормальная картина форумного мира, похожа, в общем-то :)
Предела мечтаний нет, нам тоже есть к чему стремиться и мы будем. Сейчас форумы Yii, по крайней мере, живые и приветливые. Новых членов сообщества принимают, а не отталкивают, что идёт всем на пользу. Новички через какое-то вырастают и помогают следующей волне.
Что до фанбоев, они есть в любом крупном сообществе, будь то фреймворк или, например, варезник.
Предела мечтаний нет, нам тоже есть к чему стремиться и мы будем. Сейчас форумы Yii, по крайней мере, живые и приветливые. Новых членов сообщества принимают, а не отталкивают, что идёт всем на пользу. Новички через какое-то вырастают и помогают следующей волне.
Что до фанбоев, они есть в любом крупном сообществе, будь то фреймворк или, например, варезник.
UFO just landed and posted this here
Популярность Yii предсказуема, хороший фреймворк, во время выстреливший и занявший свою нишу.
Какой из перечисленных является самым стабильным, я не компетентен утверждать, но интуитивно предположу, что это и есть Yii.
На номинацию самого развивающегося же он явно не дотягивает, судя по резко возросшему комьюнити Laravel, и нашумевшего Phalcon, первые места одназначно за ними в этой категории.
Мой же выбор, чудом не Yii, ему я в своё время предпочёл Kohana, по одной простой причине — лёгкость входа с нуля, для самообучения и обучения основ веб-разработке других. Пусть они сами же оттолкнули от себя большинство фанатов отсутствием обратной совместимости, но сама идеология у них мне по душе.
Yii тоже прост, но по опыту вышло, что с пол пинка в голове у людей он не укладывается, и я в данном случае бы назвал его скорее промышленным, профессиональным фреймворком.
Какой из перечисленных является самым стабильным, я не компетентен утверждать, но интуитивно предположу, что это и есть Yii.
На номинацию самого развивающегося же он явно не дотягивает, судя по резко возросшему комьюнити Laravel, и нашумевшего Phalcon, первые места одназначно за ними в этой категории.
Мой же выбор, чудом не Yii, ему я в своё время предпочёл Kohana, по одной простой причине — лёгкость входа с нуля, для самообучения и обучения основ веб-разработке других. Пусть они сами же оттолкнули от себя большинство фанатов отсутствием обратной совместимости, но сама идеология у них мне по душе.
Yii тоже прост, но по опыту вышло, что с пол пинка в голове у людей он не укладывается, и я в данном случае бы назвал его скорее промышленным, профессиональным фреймворком.
UFO just landed and posted this here
Что такое «порог вхождения»? И там, и там php, везде примерно одно и то же.
Ну, в Symfony 2 высок порог вхождения по сравнению даже с 1.x. Особенно если хочется писать по фэн-шую, а не чтобы работало. Тут и сервис-ориентированная архитектура, и DataMapper вместо привычного многим ActiveRecord, и мощный DI, и мало функциональности «из коробки», и не простая для схватывания на лету система бандлов.
UFO just landed and posted this here
Про карму не ко мне. Я если и минусую её, то по этическим причинам.
Сможет-то он сможет, но для sf ему понадобится больше времени.
Да, как многие инструменты, они упрощают жизнь, но и требуют времени на освоение.
Сможет-то он сможет, но для sf ему понадобится больше времени.
Да, как многие инструменты, они упрощают жизнь, но и требуют времени на освоение.
Совершенно согласен именно с данным комментарием.
Лишь выразил своё мнение.
Yii простой, но отсутствие в kohana тех же генераторов даёт возможность человеку «с нуля» въехать на более глубоком понимании кода.
Yii потому и популярен, что все велосипеды изобретены и обкатаны, но как понять их работу новичку?
Кстати kohanaframework.org попала под раздачу блокировок.
Лишь выразил своё мнение.
Yii простой, но отсутствие в kohana тех же генераторов даёт возможность человеку «с нуля» въехать на более глубоком понимании кода.
Yii потому и популярен, что все велосипеды изобретены и обкатаны, но как понять их работу новичку?
Кстати kohanaframework.org попала под раздачу блокировок.
Возможно я ошибаюсь но мне кажется сложность вхождения в ФФ обусловлено плохим или слабыми знаниями — ООП, MVC и т. д.
ЗЫ: Зачастую за выбором фремворка скрываться много факторов(не только предпочтение разработчика).
ЗЫ: Зачастую за выбором фремворка скрываться много факторов(не только предпочтение разработчика).
сложность вхождения в ФФ обусловлено плохим или слабыми знаниями — ООП, MVC и т. д.Вовсе не факт. Сложность вхождения в этом отношении у популярных фреймворков плюс-минус одинакова. У сложности, имхо, два основных фактора: простота создания типовых приложений и простота внесения изменений для нетиповой функциональности, как на фронтенде (сложные контролы, виджеты, темы и т. п), так и на на бэкенде.
Sign up to leave a comment.
PHP фреймворк 2013