Хм, много интересных вещей там есть, и удобных, но очень не понравился подход, когда на каждую глобальную сущность у них свой класс, в котором куча static методов. Хотелось бы одну общую точку, например как в Yii, Yii::app()->… а тут много-много всего самостоятельного статичного. Ну и еще немного не понравились nested controllers, это значит если я хочу вложенность в 3-4 сделать, то это будет One_Two_Thre_Four_Controller, прям как имена ZF :D Но в целом понравился) Надеюсь другие разработчики, в том числе Yii, возьмут отсюда тоже много классных идей)
Если глянуть на Kohana, то там тоже, куча статических классов. Но там мало чего из коробки есть.
ну я и говорю, что не очень нравится эта куча статических классов. Из коробки действительно тут очень много всего, чего например в том же Yii хотелось, посмотрим что будет дальше с эти fw.
Давайте будем честными и подчеркнем, что «не нравится» — это не совсем аргумент, уж простите мне мою прямоту.
Уже просмотрели и всё хорошее взяли на заметку ;)
Так давайте быстрее уже :)
По сути это может стать альтернативой YII. Уж больно они тянут со своей 2-ой веткой, а тут есть все что хотят реализовать в Yii. Хотя я все равно не вижу никаких реальных доводов для того что бы использовать этот фреймворк. Как по мне ближайшее время вряд-ли что-то круче симфонии второй появится.
Хм, не соглашусь с вами насчет «реальных доводов для того что бы использовать этот фреймворк», пусть посмотрел бегло, но все же у этого fw есть много полезных вещей и хорошая структура, что в сумме даст ускорение + улушчение качества разработки, разве это не основополагающе? Вопрос в том, что есть подсознательное «не хочу учить что-то новое», но это уже другие проблемы :)
Беда в том что я лично не увидел ничего нового и ничего «лучше». В симфони есть те же бандлы, тот же Dependency injection и т.д. И реализация там много более интересна (хотя бы аннотации, раутинг и прочие плюшки, которые здесь реализованы довольно стандартно.

The Eloquent ORM и миграции. Мне больше по душе Doctrine ORM. Я пользовался многими и субьективно, лично для себя, ничего лучше я просто не нашел. Апдейт схемы делает наличие миграций необязательными. Очень редко они мне были нужны. Вообще все намного более лаконично. Поправил модель, закомитил. Другой человек обновил у себя, выполнил команду и готово. А так после изменения модели приходится и миграцию писать. Я ленивый человек и не люблю лишние телодвижения для достижения желаемой цели. Да и AR любит память жрать. Тут к слову было бы неплохо разработчикам фреймворка подготовить какой-нибудь бенчмарк.

no-sql из коробки — ну… клево, да. Правда у Doctrine тоже есть ODM.

Обширная коллекция бандлов — чуть менее 100. Большая часть из которых лишь сервисы для DI. На то он и DI что бы можно было легко любую библиотеку в сервис превратить.

Подытожив: я не буду пользоваться этим фреймворком. Покрайнемере пока не увижу явных плюсов перед симфони 2. Ну или по работе придется.

p.s. Я сам был приверженцем Yii, но по работе заставили разбираться с Symfony 2. По началу да, плевался, но затем… словом, как я уже говорил, врят-ли ближайшее время появится что-то кардинально новое.
Да, полностью согласен по поводу Symfony и без упрека в сторону Laravel. Сейчас пишем проект на Symfony 2.3 — полностью покрывает все необходимое в разработке — (Хотя часто вижу высказывания, что порог вхождения в Symfony высокий — я думаю просто нужно привыкнуть к тому, что можно получить все через DI). И по поводу аннотаций — просто сказка. Нужно ACL повесить над роутингом — пожалуйста, добавляем в аннотацию и все (предварительно подключив бандл JMSSecurityExtraBundle ).
«recovery mode» на хабре…
Так и думал что напишут про этот фреймворк :)
причем здесь recovery mode?
Ошибся.
Спасибо за пост!
Супер. Всю карму слили
ой беда, огорчение
Ещё одна попытка скопировать Rails. Смотрел только ORM, почти 1 в 1 ActiveRecord, только с PHP синтаксисом смотрится не очень.
Паттерн Active record был описан в 2003-ем году, когда как RoR вышла в 2004-ом. Объясните же мне, почему все слизано именно с RoR?
Потому что ActiveRecord – это не только название паттерна, но также и название библиотеки Rails. И не все, кто говорят «ActiveRecord» даже слышали про Фаулера.
Гениальное логическое умозаключение. Я так подозреваю, что если в рельсах есть Controller, то в остальных fw на других ЯП, в которых есть данный тип объектов, тоже все слизано с рельс? мда…
При чем тут слизано? Вы слышали про термин «контекст употребления»? В зависимости от контекста это имя собственное может значить либо одно, либо другое. В примере сверху очевидно, что речь шла про _библиотеку_, а не про паттерн. Но конечно легче троллить и умничать, чем знать о существовании и того, и другого.
K чему наезд?
«И не все, кто говорят «ActiveRecord» даже слышали про Фаулера.» — это же тонкий стеб над «Ещё одна попытка скопировать Rails. Смотрел только ORM, почти 1 в 1 ActiveRecord, только с PHP синтаксисом смотрится не очень.».
Блин, это тоже называется фрейсворком… ну ты подумай, все воруют у RoR
буд-то это плохо…
Когда уже сделают чтобы людей подписанных на ruby не пускали в php хабы.
Смысл?
Есть среди них люди с рельсами головного мозга, но есть и вполне адекватные.
Просто у некоторых в голове версии гемов конфликтуют )))
Я так и не понял, чем-же этот фреймворк круче Symfony или других фреймворков? Например при задании в поиске тупо: «i18n» мне ничего не выпало? Получается, интернационализация отсутствует? Хорошо, а ОРМ взяли откуда — контрол+це, контрол+ве? Редис?! Он типа везде стоит как дефолт, правда? И что-же получается? Как всегда, фреймворк для быстрого написания (говно)кода, чтобы код веб странички не выглядел как говнокод и не казался слишком «гламурно-тупым» для новичков? Зато да, используете «фреймворк».
Или я чего-то не усёк?

ПС: я так, маслица в огонёк подлил. Если чё, минусуя обьяснайте в чём не прав…
Каждый новый FW теперь обязан быть круче Symfony или других фреймворков?
Как сегодня было сказано в одном из топиков:
это всего лишь дело вкуса
Дело вкуса это конечно хорошо, но обычно выбирают инструменты все же для работы. А для работы важно что бы это работало. Причем желательно что бы и через год фреймворк развивался, поддерживался, количество расширений росло. Рассматриваются перспективы, качество реализации и т.д. и т.п.

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

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

Почему никто не сделает нормальный человеческий демон на PHP? (их уже много конечно, но тут развернуться в плане возможностей и альтернатив есть куда) Ну или там, аналог CoffeeScript для php (какие-нибудь надстройки, синтаксический сахар, нормальные названия методов, функций и прочего) для более удобной и функциональной разработки? (в симфони вот ввели аннотации, которые, судя по всему, в сам язык введут ой как не скоро, если вообще введут)
С таким подходом:
Sinatra не нужен в мире Ruby, поскольку RoR – мейнстрим.
Mootools, CoffeeScript не нужны в мире JS — есть jQuery и JS сам по себе.
Play не нужен в Java – нафига, уже есть Spring.

Продолжать?
Ваша цепочка не совсем корректна:
Я хоть и далек от рабби, но синатра больше похожа на микрофреймворк. А вот RoR — тормознутый монстр (извините за бестактность, быть может мои впечатления устарели). Цели использования у них изначально разные, разные целевые группы. Тут все гуд.

Mootools сравнивать с jQuery тоже несколько некоректно. Если вы выбираете библиотеку для работы с DOM то да, mootools вам не нужен. Но если вы пишите сложное приложение то вам понадобится более мение удобная структура. Хотя сейчас есть backbone+underscore+jquery.

кофескрипт — тут я промолчу. Лично мне он никогда не нравился, потому субьективно я настроен против. Хоть и понимаю что штука возможно полезная.

Play и Spring не видел. С Java знаком лишь на уровне универа. Мне больше как-то C# подуше.

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

PS Прибегут апологеты руби и залинчуют вас за «рабби». Если что, я не при делах :)
Да, не спорю, симфони зачастую избыточен. Как допустим использование MySQL там, где хватило бы обычных файлов ну или хотя бы простенькое NoSQL Хранилище. Есть множество микро-фреймворков. Тот же Silex, который построен на симфони. Да много их разных. Но ведь и сабж избыточен. Так зачем он мне? у меня уже есть неплохой фреймворк который с лихвой покрывает все мои нужды. Мне вообще концепция узконаправленных библиотек нравится, и не радует меня попутки реализовать универсальную систему. Чем мне нравится симфони, и пожалуй это ее основное преимущество, ты не привязываешь компоненты системы к архитектуре фреймворка. Это делает все очень гибким.

PS Прибегут апологеты руби и залинчуют вас за «рабби». Если что, я не при делах :)

Я заслужил… чего уж там.
Мейнстрим хорош тем, что вам не придется писать много документации и объяснять новичкам особенности своих хипстерских фреймворков. Симфонист разберется в симфони проекте гораздо быстрее, чем в laravel проекте и т.п.

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

=)
Во все времена все новое должно было доказывать свою состоятельность. Каждый раз, когда читаю о том, что вышел новый PHP-фреймворк, убеждаюсь в двух вещах:

1. Что сделал правильный выбор, выбрав Kohana,
2. Что правильно делаю, изучая Erlang и чуть-чуть NodeJS.

Хотя к PHP у меня нету противления, как у некоторых ненавистников. Это инструмент со своей конкретной целью.
В буржунете сейчас идет волна ня-обожания Laravel, особенно после поста philsturgeon.co.uk/blog/2012/05/laravel-is-awesome. (Fuelphp, кстати, впал в немилось, из-за планируемого перехода на PSR-1 с кемел-кейсом, и вообще он уже не ня). И такое ощущение, что народ не видел Кохану вообще. Почти никто её не вспоминает и не сравнивает с ней. Такое ощущение, что все до сих пор сидят на CodeIgniter и отсутствие singleton для них уже мегапрорыв и разрыв шаблонов.

Интересно, почему Кохана растеряла всех codeigniter-свитчеров? Ведь это прекрасный простой (если не лезть в глубь и работать по шаблону) фреймворк, как раз для ЦА laravel?
Слишком частое изменение API, не совместимые с предыдущими версиями. Например, код под 3.1 не будет работать на 3.0. Плюс, не поспевает документация, мало наработок (это уже следствие изменения апи), игнор девелоперов со стороны разработчиков фреймворка и т.д.
Я с вами соглашусь, но только отчасти. Последний раз изменение API затронуло только работу с конфигами (это вообще была ерунда). Единственное серьезное изменение было, на моей памяти, связанное с контроллерами. И тут вы не правы — как раз-таки, код, написанный под 3.2 в этом плане был совместим с ранними версиями. А это означает, что перейти к поддержке ядра 3.2 было можно заранее. Я могу всего не помнить, конечно, но особенных трудностей не ощутил.

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

По поводу же отсутствия желания прислушиваться у разработчиков я согласен только отчасти. Часто к ним пристают с какими-то глупостями. Вы почитайте форум — иногда там творится АДЪ.
А до этого, с 3.0 на 3.1, меняли Validate на Validation + Valid, вводили Request — это довольно обширные изменения были. brotkin.ru/2011/01/10/ko-31-rc1
Вспоминл, да. Только, почему-то, я к ним не отнесся так болезненно… Все довольно гладко у меня прошло.
В 3.1 появился response, изменилась валидация, пропали фильтры и callback-и в валидации (которые, между прочим, часто использовались).
В 3.2 изменились конфиги, изменился request (например, пропал метод url), кое-какие мелкие изменения.
В 3.3 изменились Controller, HMVC, HTTP_Exception (это вообще весело), request (снова! пропал redirect, изменились параметры в factory, пропал response), Autoload (!!! вообще ломающий старый код) и т.д.

В общем, каждое обновление ломает рабочий код (
У меня настроение под конец дня ироничное… с другой стороны, можно считать, что каждая новая версия Коханы — отдельный фреймворк.

Я как-то не следил за развитием ветки 3.3 в Кохане — в ближайшее время ознакомлюсь. Очень интересно, чем они все это объясняют.
Есть такая работа — новшества прославлять (с).

Я у Коханы внутри ничего такого сложного не обнаружил. Единственная сложность, с которой столкнулся — что в интернете гайды и хауту по ней пишут люди, которые решают задачи, а не создают инструменты для решения задач. К примеру, этот знаменитый монстр, демонстрирующий работу oAuth. Ужас-ужас.
Раньше у Фила была другая работа — разрабатывать CodeIgniter и FuelPHP. Поэтому такой вот поклон в адрес прямого конкурента людей поразил.
Ну посмотрим, что из этого выйдет.
На самом деле это это был не столько поклон, сколько оправдание неповоротливости CodeIgniter в плане технологических улучшений — ведь и правда, вносить кардинальные изменения в движок, которые ломают функциональность работающих приложений, — это проявление неуважения к пользователям продукта. Кстати, сабж на протяжении трёх версий менялся кардинально, но это можно списать на его молодость.
Запоздало влез, но да, Mootools, CoffeeScript не нужны в мире JS — есть jQuery и JS сам по себе. Тут полностью согласен, не нужны они там. Про остальные технологии не знаю.
«каждый защищает свое г**но» — тут уже больше дело вкуса… так как есть люди для которых Zend круче всего на свете, у других это Yii и т.д. по списку. Говно можно писать и на Symfony, и на всех остальных, так что, не нужно тут поднимать шуму, или быть уверенным что есть FW который не даст написать говно-код.
Интернационализация там есть.
Он не круче, он проще. Если Symfony это RoR, то Laravel скорее Sinatra. Taylor Otwell его начал писать год назад, чтобы с чистого листа сделать простой и человечный php-фреймворк, без груза обратной совместимости и с радостями 5.3 (а именно замыкания) и наработок из RoR и других фреймворков. Получилось в целом неплохо. Это для людей, которые начинали не с Zend, а с Codeigniter. Для ремесленников, а не для живописцев.
Вот тоже, слоган довольно странноватый. Обратил внимание, да.
Перевод некоторых статей на русский: laravel.ru/
Полезные ресурсы и ссылки для quick start: laravel.ru/forum/viewtopic.php?id=16

Про laravel обещал написать Александр Макаров (Sam Dark), один из разработчиков Yii. C вот такой вот затравкой, опубликованной неделю назад в твиттере:
«Смотрю фреймворк laravel. Некоторые штуки красивы, но есть и фатальные для выстраиваемых на нём приложений ошибки.»
HTML::macro('my_element', function()
{
    return '<article type="awesome">';
});
 
echo HTML::my_element();

Я, признаться, слегка обалдел, когда такое увидел. Это же как надо ненавидеть HMVC.

Но я не холивары сюда разводить пришел. Мне интересно, вот вы пишете про ORM:
Сами отношения классические. Такие, какими они были во времена становления Rails и Prado.
А что вы имеете в виду, расскажите подробнее?
Четыре стандартных типа отношений: HAS_ONE, HAS_MANY, BELONGS_TO, MANY_MANY.
Пардон, хотел узнать про нестандартные
Нестандартно будет в Yii2. Там не будет, например, MANY_MANY. Да и вообще каких-либо ограничений на тип и способ связей.
Так и не встретил раздела «Итак, фатальные для меня штуки». А было бы интересно.
Самые фатальные в разделе «ORM, из нехорошего» + излишнее использование статики.
«Массовое присвоение в ORM включено по умолчанию».
В условиях необязательной валидации в моделях разработчик теоретически может выстрелить себе в ногу. Понятно, что с нашей точки зрения он сам себе кузнец своего счастья, но с точки разработчика фреймворков это серьезная уязвимость.
Имеет право на жизнь! Однако от статьи я ожидал раскрытия темы, примеров кода, примеров приложений/сайтов исполненных на данном FW. А так… просто ссылка: Тут вот такое появилось — сходите по ссылке…
Кстати, примеры есть на завлекательном лэндинге getlaravel.com
Выше много уже было сказано о разном. И про ORM, и про Symfony… даже про RoR — а я скажу про HMVC.

Уже как-то привык абстрагироваться от ядра в Kohana (да, глобальная область там заполнена статичными и не очень классами), но это тоже дело вкуса… Надо где-то улучшить? Без проблем… где-то баг, в какой-то библиотеке? Ничего страшного — все решим.

Как причина номер два: я говорил, говорю и не перестану говорить, что наличие assert-функционала лично для меня является скорее минусом, чем плюсом. Я не вижу никаких препятствий тому, чтобы написать пару phing-тасков, которые будут сливать всю статику в один файл, сжимать ее чем угодно (некоторые даже гзипуют ее и кладут два варианта — так они любят свои сервера)… да блин, можно даже png/jpeg оптимизировать перед деплоем…

Но самое главное — это HMVC. Точнее, его отсутствие.

Так что пользоваться не стану.
HMVC есть, он добавляется бандлом: bundles.laravel.com/bundle/hmvc
Да видел я… но все-равно, как-то это больше танцы с бубном напоминают.

Как, например, вот этот бандл bundles.laravel.com/bundle/zendframework
их ОРМ (Eloquent) очень кривой. например вот как работает eager loading:

foreach (Book::with('author')->get() as $book)
{
echo $book->author->name;
}
In the loop above, only two queries will be executed:

select * from books

select * from authors where id in (1, 2, 3, 4, 5, ...)


Та же кохана делает такое одним запросом с лефт джойнами.
Представте себе теперь что у вас 10000 books, в случае ларавел алогоритм выберет все 10000, пройдет по ним, соберет айдишки, создаст запрос с айдишками через кому (кстати если если нужно поддгрузить больше связей то запросов будет больше, и учтите что есть ограничение на размер параметров в IN ), потом пройдется по масивам еще раз и соединит books и authors. Памяти выжрет вагон.

Вот в той же PHPixie о которой я писал создатся один запрос с джойнами и в памяти всегда будет только 1 книга и ее автор (так как будет использоватся курсор для прохода по строчкам резульата запроса).
Только полноправные пользователи могут оставлять комментарии.
Войдите, пожалуйста.