Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 90
Уже давольно давно присматриваюсь к этому фреймворку, и вот сейчас, наконец, появилась возможность сделать на нём новый проект. Новая версия как нельзя кстати!
Она немного сырая еще (учитывая, что релиза не было), но начинать смотреть ее очень стоит.
Это не тот фреймворк, который в ближайшее время может быть заброшен и прекратить развитие =)
Это не тот фреймворк, который в ближайшее время может быть заброшен и прекратить развитие =)
Я бы тоже не советовал на 5-ке делать что-то серьезное. Надо немного подождать. Помнится 4-ка стала более менее юзабельной к 4.1
Отличный пост, большое спасибо!
Остается только добавить, что релиз пятой версии будет в ноябре :)
В этой статье я хотел бы написать о новой версии Laravel, официальный релиз которой состоится в ноябре, но скачать и попробовать которую можно уже сейчас через Composer.
Уже было в статье :)
Оу, тогда прошу извинить, пробежался по посту по диагонали, не заметил :)
Все же, учитывая частоту коммитов в github.com/laravel/laravel/commits/develop стоит предупредить народ, что начинать проекты на пятерке сейчас не стоит, даже к бете может все очень сильно измениться внутри.
Вообще могу конечно упомянуть это в статье, но вот сам Laravel уже перевел свой сайт на 5 версию.
twitter.com/taylorotwell/status/514090413414572032
twitter.com/taylorotwell/status/514090413414572032
Спасибо за прекрасную статью, прочитал на одном дыхании. Пишите еще.
А не присматривались к Yii2, RC выходит через пару дней, он тоже хорош, а автокомплит в PhpStorm просто волшебный.
Пока метаюсь между ними и пытаюсь понять, что же удобней, но коммьюнити у laravel все таки помощнее, одни только laracasts чего стоят.
А не присматривались к Yii2, RC выходит через пару дней, он тоже хорош, а автокомплит в PhpStorm просто волшебный.
Пока метаюсь между ними и пытаюсь понять, что же удобней, но коммьюнити у laravel все таки помощнее, одни только laracasts чего стоят.
Yii 2, имхо, стоит смотреть тем, кто уже привык к первой версии, всем же, кто присматривается к совершенно новому для себя фреймворку — я бы посоветовал именно Laravel.
У Laravel в PhpStorm тоже есть автокомплит, на laracasts есть 2ух минутный урок где объясняется как это сделать, это 15ый из бесплатной серии уроков по PhpStorm. Используется Laravel IDE Helper и он подходит не только под PhpStorm, но и под другие IDE (лично проверял только на PhpStorm).
Попробовал оба (yii2 и laravel 4).
Я остановился на Yii2. Главная причина — более удобная работа с формами и валидация в моделях (в ларавел нет встроенной валидации моделей).
А так — оба фреймворка чем то похожи. Даже ларавеловские фасады похожи на компоненты yii.
Ну и такие фишки у Yii, как gii (для генерации кода), Grid, DataProvider, RBAC из коробки и тд — после того как поработаешь с ними, чуствуешь, что чего не хватает в других фреймворках.
Я остановился на Yii2. Главная причина — более удобная работа с формами и валидация в моделях (в ларавел нет встроенной валидации моделей).
А так — оба фреймворка чем то похожи. Даже ларавеловские фасады похожи на компоненты yii.
Ну и такие фишки у Yii, как gii (для генерации кода), Grid, DataProvider, RBAC из коробки и тд — после того как поработаешь с ними, чуствуешь, что чего не хватает в других фреймворках.
Валидацию специально вынесли отдельно, дабы не перегружать модели. До этого все далали по разному, как правильно заметили в статье. В новой версии с импрувнутым валидатором веротяно процесс как-то унифицируется. По поводу фишек типа gii и прочих, то тут тоже умышленое избегание перегрузки функционалом. Все это есть, все это активно используется, но вынесено в отдельные компоненты. Composer в помощь
В том то и дело, что речь об удобстве. Валидация внутри моделей очень удобна.
Я только ради этого функциоанала остался на yii
А по поводу composer — так он подключается везде, в том числе и в yii2. Другое дело, что в yii есть из коробки работа с RBAC c хорошей описанной документацией, а в ларавел надо что-то искать, подключать, разбираться. А DataProvider? Я вообще больше нигде не встречал ничего похожего (ну кроме views в друпале). Лично мне кажется, что скорость разработки благодаря встроенным компонентам в yii повышается.
Вот что действительно удобно, чего мне не хватает — это мощное консольное приложение в Laravel.
Ну и Queues. Хотя, поддержку очередей можно уже доустановить через тот же composer.
$model->load($_POST);
if(!$model->save()){
...
}
Я только ради этого функциоанала остался на yii
А по поводу composer — так он подключается везде, в том числе и в yii2. Другое дело, что в yii есть из коробки работа с RBAC c хорошей описанной документацией, а в ларавел надо что-то искать, подключать, разбираться. А DataProvider? Я вообще больше нигде не встречал ничего похожего (ну кроме views в друпале). Лично мне кажется, что скорость разработки благодаря встроенным компонентам в yii повышается.
Вот что действительно удобно, чего мне не хватает — это мощное консольное приложение в Laravel.
Ну и Queues. Хотя, поддержку очередей можно уже доустановить через тот же composer.
просто добавляли метод в модель, например так
и потом в нужных методах той же модели, например вот так:
можно навесить на констурктор модели и тогда получим как примерно тоже самое, как у тебя в примере.
Такая фривольность, очевидно, имеет свои минусы, но именно поэтому мне фреймворк и понравился. Чувствуется, что не ты работаешь на фреймворк, а фреймворк рабтает на тебя.
public function validate($data)
{
$validator = Validator::make($data, Post::$rules);
if($validator->fails()) throw new ValidationException($validator);
return true;
}
и потом в нужных методах той же модели, например вот так:
public function store($data)
{
$this->validate($data);
return Post::create($data);
}
можно навесить на констурктор модели и тогда получим как примерно тоже самое, как у тебя в примере.
Такая фривольность, очевидно, имеет свои минусы, но именно поэтому мне фреймворк и понравился. Чувствуется, что не ты работаешь на фреймворк, а фреймворк рабтает на тебя.
В том то и дело, что нужно добавлять, что-то доделывать. А тут — не сохранилось, показываем почему не сохранилось (передаем в шаблон эту модель, в которой все свойства уже заполнены, все ошибки уже прописаны). Более того, yii (что 1й что 2й) умеет делать ajax валидацию. Т.е. работа с формами и моделью сводится к выводу input поля и попытки сохранить данные. Все остальное фреймворк сделает сам. Если не сохранилось — сам покажет и заполнит форму, покажет ошибки и тд. Но, валидация модели ещё хороша тем, что делается только 1 раз и забываешь про это. Т.е. если мы хотим заполнить данные модели вручную (не на основе данных, которые пришли из броузера, а, допустим, при выполнении какой-то фоновой задачи, воркера
то данные будут отвалидированны. Супер. Ну и конечно всё это можно обойти, не использовать, или использовать свои методы. Всё очень гибко.
На счет кто на кого работает — это уже довольно субъективно :)
$model = new Post();
$model->a = 'a';
$model->b = 123;
$model->save();
то данные будут отвалидированны. Супер. Ну и конечно всё это можно обойти, не использовать, или использовать свои методы. Всё очень гибко.
На счет кто на кого работает — это уже довольно субъективно :)
В yii все хорошо, пока не понадобится вывести, например, дату для редактирования (в бд метка времени, а в форме — строка) или любые другие поля которые в редактируемом виде отличаются от того что хранится в базе. Вот тогда начинаются всякие извращения (использую самописное поведение для прозрачной конвертации между оригинальным полем и фейковым полей строкой).
в Yii2 встроенный мощный форматтер на базе intl
В L4 на базе Carbon
Я не про форматирование говорил: пусть есть модель с полем
Единственный найденный выход это добавить фейковое текстовое поле для отформатированной даты, повесить на него валидатор с сохранением полученной метки времени в
Или в yii 2 эта проблема уже решена?
date, которое хранится в бд в виде метки времени, пользователь его вводит в виде «dd.MM.yyyy HH:mm», как его нормально вывести, валидировать и сохранить? Первое что приходит на ум и что везде гуглится это повесить валидатор на `date` и потом где-то перед сохранением модели добавить конвертацию этой строки обратно в метку времени. Вот только это чрезвычайно кривое решение, потому что в одно время поле хранит строку, а в другое — число => никогда не знаешь что там окажется…Единственный найденный выход это добавить фейковое текстовое поле для отформатированной даты, повесить на него валидатор с сохранением полученной метки времени в
date (благо сам валидатор это умеет) и написать код для синхронизации значение этих двух полей. Несколько через жопу, не правда ли?Или в yii 2 эта проблема уже решена?
не могу точно сказать. Есть глобальные настройки для вывода дат.
В вашем случае не надо ничего фейкового делать, достаточно написать поведение на два события: afterFind и beforeValidate, с двумя аргументами outputFormat и inputFormat.
В вашем случае не надо ничего фейкового делать, достаточно написать поведение на два события: afterFind и beforeValidate, с двумя аргументами outputFormat и inputFormat.
И потом поиметь проблем в различных местах приложения когда в поле вместо метки времени окажется строка (или наоборот)? Нет, спасибо, уже сталкивался. Поэтому теперь всегда использую отдельные поля для отформатированных значений.
почему вместо метки времени придет строка? дайте кейс.
Если я не ошибаюсь, то вы имели в виде что-то наподобие?
В итоге получаем:
1) После поиска field строка
2) После сохранения там уже число (метка времени)
А теперь, где-то в приложении есть следующий код:
Пусть
1) Вызвав метод с
2) Вызвав метод с этой же
Пример реальный, гарантировано доставляет огромную кучу радости при отладке и попытках заставить работать со всеми моделями (особенно когда с yii только начинаешь работать).
class MyModel extends CActiveRecord {
protected function afterFind () {
$this->field = 'конвертируем в строку';
parent::afterFind ();
}
protected function beforeValidate () {
$this->field = 'конвертиуем в метку времени';
return parent::beforeValidate ();
}
}
В итоге получаем:
1) После поиска field строка
2) После сохранения там уже число (метка времени)
А теперь, где-то в приложении есть следующий код:
public function search(MyModel $model) {
$search = new CDbCriteria();
$search->compare('myfield', $model->field);
// .....
}
Пусть
myfield это поле типа INT, тогда:1) Вызвав метод с
MyModel созданной при поиске — получаете ошибку2) Вызвав метод с этой же
MyModel, но после её сохранения, всё работает как и задумывалось.Пример реальный, гарантировано доставляет огромную кучу радости при отладке и попытках заставить работать со всеми моделями (особенно когда с yii только начинаешь работать).
да, конечно нужно еще добавить третье событие afterSave
и нет, я не имел в виду такой прямой подход — я имел в виду поведение (behavior)
и нет, я не имел в виду такой прямой подход — я имел в виду поведение (behavior)
Только на afterValidate наверное (а этого кстати нет во многих примерах которые можно нагуглить). Но, в любом случае, с двумя полями получается гораздо проще/лучше, тем более внутри приложения метка времени нужна чаще чем то, что видит пользователь при выводе/редактировании (собственно у меня форматированная дата только им и используется, в коде везде числа).
В yii все модели наследуются от Component.
Поэтому можно использовать встроенные геттеры и сеттеры.
Допустим в базе хранится в поле created_at = 1412676897;
В модели пишем так:
Ну и потом используем в шаблонах
— Опа, решил ответить после обеда и страницу не обновил, а тут выше целая дискуссия развернулась.
Поэтому можно использовать встроенные геттеры и сеттеры.
Допустим в базе хранится в поле created_at = 1412676897;
В модели пишем так:
public function getCreated(){
return date("Y-m-d H:i", $this->created_at);
}
Ну и потом используем в шаблонах
echo $model->created;
— Опа, решил ответить после обеда и страницу не обновил, а тут выше целая дискуссия развернулась.
Это всё понятно, но нужен еще setter и где-то хранить введенную пользователем строку до момента валидации и сохранения, а потом еще захочется чтобы эти поля были синхронизированы и… рано или поздно пишется поведение для автоматизации всего этого:
/**
* @property integer $time метка времени (то что хранится в бд)
* @property string $timeDatetime отформатированная дата (фейковое поле)
*/
class MyModel extends CActiveRecord {
/**
* @return array
*/
public function rules() {
return array_merge(parent::rules(), [
['timeDatetime', 'required'],
['timeDatetime', 'date',
'format' => 'dd.MM.yyyy HH:mm',
'timestampAttribute' => 'time'],
]);
}
/**
* @return array
*/
public function behaviors() {
return array_merge(parent::behaviors(), [
'timeAttribute' => [
'class' => 'TimeAttributeBehaviors',
'attributes' => [
'time' => null, // формат, но не обязательно
],
],
]);
}
/**
* @return array
*/
public function attributeLabels() {
return array_merge(parent::attributeLabels(), [
'time' => 'Дата и время',
'timeDatetime' => 'Дата и время',
]);
}
/**
* @return void
*/
public function refresh() {
$this->timeDatetime = null;
return parent::refresh();
}
}
А может кто-то сказать чем лучше yii 2? Со стороны смотрю на это чудо, и кажется что это тот же yii.
Из лагеря Laravel:
* Why Laravel better then Yii?
* Laravel 4.x and Yii 2.0 Beta
Из лагеря Yii:
* Yii 2.0 vs. Laravel
* How Does The Yii Deal With The Challenges From Laravel?
Ну и куда ж без тостера:
* Laravel или Yii — на чем лучше на данный момент начинать разработку сайта? В чем отличия?
* Why Laravel better then Yii?
* Laravel 4.x and Yii 2.0 Beta
Из лагеря Yii:
* Yii 2.0 vs. Laravel
* How Does The Yii Deal With The Challenges From Laravel?
Ну и куда ж без тостера:
* Laravel или Yii — на чем лучше на данный момент начинать разработку сайта? В чем отличия?
А я вот так делаю =-)
propel diff
propel migrate
propel model:build
propel diff
propel migrate
propel model:build
В варианте с yii ошибка, $this->batchInsert('{{%lang}}', ...)
А в примере ларавел есть один большой подводный камень. Если в будущем изменится название таблицы lang, миграция с нуля не сработает. Т.к. в момент выполнения этого шага у нас имеется таблица lang, а в коде модели будет прописана таблица language, например.
Имхо, гибкость миграций yii доставляет больше, т.к. свойства полей описываются привычным sql синтаксисом, и можно точно сказать какое поле будет создано — varchar(255) или text, например.
А в примере ларавел есть один большой подводный камень. Если в будущем изменится название таблицы lang, миграция с нуля не сработает. Т.к. в момент выполнения этого шага у нас имеется таблица lang, а в коде модели будет прописана таблица language, например.
Имхо, гибкость миграций yii доставляет больше, т.к. свойства полей описываются привычным sql синтаксисом, и можно точно сказать какое поле будет создано — varchar(255) или text, например.
Я думаю, что вы хотели показать какие классные краткие миграции у L4. Но вот из вашего примера, я совершенно не понимаю, какие поля разрешают NULL, какие — нет, какая длина строковых ключей, какой engine, какая кодировка и т.п. Наверняка это настраивается, но с дополнительными параметрами окажется что пример будет не таким уж и кратким.
Ну посмотрите хотя бы на AR, на автозагрузку, все стало гораздо удобнее.
Еще раз: ни единая строчка кода из метода store не будет исполнена, если форма не проходит валидацию.
Как будет реагировать если форма не приходит валидацию?
А где можно почитать про существенные отличия от других популярных фреймворков?
Я недавно тоже попробовал Laravel, почти всё понравилось, но в целом достаточно всё похоже на другие фреймворки, хотя конечно я глубоко его не изучал, прошелся по основным функциям — конфигурация окружений, MVC, работа с БД, авторизация…
Я недавно тоже попробовал Laravel, почти всё понравилось, но в целом достаточно всё похоже на другие фреймворки, хотя конечно я глубоко его не изучал, прошелся по основным функциям — конфигурация окружений, MVC, работа с БД, авторизация…
Я бы еще порекомендовал посмотреть эти скринкасты, там все довольно подробно рассказано про все нововведения :)
Я не считаю себя гуру в php и фреймворках. До этого пару раз работал с первым и вторым зендом, бессмертным битриксом, сталкивался с Yii и Symphony, изобретал велосипеды сам, но каждый раз у меня оставалось смутное чувство неудовлетворенности.
Переходите уже на Rails, будет меньше отрицательных смутных чувств :)
Мог бы стать идеальным фреймверком если бы не статические вызовы ((
Решение: Удалить алиасы из app/config/app.php и использовать внутренности напрямую. Или из внутренностей регистри приложения, например:
app('auth')->user;
// вместо
Auth::user;
Хм, а это не плохая мысль, надо будет внимательнее изучить такую возможность.
Предлагаю попробовать посмотреть как запускается L4 — это очень много скажет о том, как он устроен и как с ним можно извращаться =)
Наверное достаточно будет разобраться с этим хелпером: github.com/laravel/framework/blob/4.2/src/Illuminate/Foundation/start.php
Наверное достаточно будет разобраться с этим хелпером: github.com/laravel/framework/blob/4.2/src/Illuminate/Foundation/start.php
Посмотрел код, получается на самом деле все статические вызовы, это всего лишь обвертка. И по хорошему можно с таким же успехом все завернуть в свою обвертку, и работать с нормальным ооп =D
Тоже вначале сильно смутило что слишком много статики, но почти вся статика это по сути фасады и на самом деле они проксят запрос к объекту внутри App. Т.е. на самом деле можно все их дергать прямо через App, но во вьюхах реально удобно именно через фасад — например при генерации форм {{ Form::open… весьма удобно
Статические вызовы — это просто сахарок для контейнера. laravel.com/docs/4.2/facades
Т.е. изначально есть
$app->make('cache')->get('key');
для него создается фасад Cache с обработчиком __callStatic(), чтобы можно было писать так
Cache::get('key')
Хотя, конечно, все равно как-то криво. DI тем и хорош, что по описанию конструктора сразу понятно, какие сервисы там используются. А так понатыкают вызовы этих фасадов по всему коду, и выясняется, что класс завязан на 20+ других классов, хотя можно обойтись 2-3.
Т.е. изначально есть
$app->make('cache')->get('key');
для него создается фасад Cache с обработчиком __callStatic(), чтобы можно было писать так
Cache::get('key')
Хотя, конечно, все равно как-то криво. DI тем и хорош, что по описанию конструктора сразу понятно, какие сервисы там используются. А так понатыкают вызовы этих фасадов по всему коду, и выясняется, что класс завязан на 20+ других классов, хотя можно обойтись 2-3.
Нет там никаких статических вызовов :)) Честное слово, этот вопрос в интернете задает каждый второй, кто только увидел Laravel.
С Laravel не работал, но то обстоятельство что у них похоже вообще больше нет публичного списка багов (или есть? где?) и единственный способ запостить баг это использование liferaft, очень сильно способствует тому чтобы о нем просто забыть…
Активные разработчики, с багами все на самом деле печально или я ошибаюсь?
Активные разработчики, с багами все на самом деле печально или я ошибаюсь?
Работаю с Laravel еще с 3-ей версии. За всё это время только в одной версии был обнаружен критический баг, который на следующий день уже был исправлен.
Поэтому в стабильных версиях всё нормально. А в dev версиях — бывают, конечно.
Поэтому в стабильных версиях всё нормально. А в dev версиях — бывают, конечно.
Поэтому в стабильных версиях всё нормально.
Я иногда работаю с yii 1.x, критичных багов там вроде давно уже нет, но регулярно возникают мелкие проблемы, например, из последнего: были проблемы с
CGridView при включении history переставал работать .update что полностью ломало поиск. Минут через 15 был найден соответствующий баг на гитхабе (#2017, он до сих пор открыт) и импортирован в проект. Если бы не трекер, пришлось бы потратить кучу времени для решения этой проблемы…критический баг, который на следующий день уже был исправлен.
Похоже что теперь вы о нем узнаете в лучшем случае после выхода нового релиза (у того же yii это может очень много времени занимать).
Ну, вот как-то не появляются мелкие проблемы. Ну, или они моментально фиксятся, что я даже заметить не успеваю.
Я читаю твиттер laravel и Тэйлора. Если что-то критическое появляется, информация об этом есть в твиттере.
Похоже что теперь вы о нем узнаете в лучшем случае после выхода нового релиза (у того же yii это может очень много времени занимать).
Я читаю твиттер laravel и Тэйлора. Если что-то критическое появляется, информация об этом есть в твиттере.
Тейлор сам на своём сайте ещё пишет, почему он решил что-то использовать и как это по его мнению правильно делать.
taylorotwell.com/
Читаю тоже по утрам. Думаешь это баг, а это фича :)
taylorotwell.com/
Читаю тоже по утрам. Думаешь это баг, а это фича :)
А как обстоят дела со скоростью у Laravel по сравнению с Yii2?
В своё время сравнивал его ещё с первым Yii на «hello world», так Laravel тогда сильно разочаровал.
В своё время сравнивал его ещё с первым Yii на «hello world», так Laravel тогда сильно разочаровал.
Честно говоря, мне уже очень давно не попадалось объективных тестов скорости фреймворков. Сейчас все больше развлекаются, тестируя приложения «Hello, world» либо меряя, что быстрее — echo или print ;) А вам?
«Hello world» позволяет прикинуть оверхед фреймворка.
Что касается бенчмарков, то на techempower.com кое-что есть. К сожалению Yii там отсутствует.
Что касается бенчмарков, то на techempower.com кое-что есть. К сожалению Yii там отсутствует.
Как всегда зависит от задач.
Очевидные тормоза в Laravel'e это фасады. Магия, магия.
DIC сам по себе достаточно прост и не тормознутный (разве что сам DI через рефлексию может напрягать, особенно с учетом изменений в 5ой версии), заросы через Symfony'вский HttpRequest идут.
Eloquent быстрее чем Doctrine, но попроще.
Ну а вообще, стандартный ответ — нужна скорость? не пишите на PHP, либо переходите на экзотику типа HHVM / Phalcon / ReactPHP.
Очевидные тормоза в Laravel'e это фасады. Магия, магия.
DIC сам по себе достаточно прост и не тормознутный (разве что сам DI через рефлексию может напрягать, особенно с учетом изменений в 5ой версии), заросы через Symfony'вский HttpRequest идут.
Eloquent быстрее чем Doctrine, но попроще.
Ну а вообще, стандартный ответ — нужна скорость? не пишите на PHP, либо переходите на экзотику типа HHVM / Phalcon / ReactPHP.
Symphony
Symfony же?
Интересная статья. Особенно понравилось, что автор сначала говорит как там все хорошо и ему нравится Laravel, а потом описывает, что пятая версия решает много «костылей», делавшихся в четверке.
Автору спасибо — прочитал на одном дыхании!
Интересует мнение разработчиков на тему Symfony 2.5 vs Laravel 5. Я трогал только Symfony 2.5 — очень понравился — после Symfony 1.4 как глоток свежего воздуха (для тех кто все еще думает переезжать ли с Symfony 1.4).
Автору спасибо — прочитал на одном дыхании!
Интересует мнение разработчиков на тему Symfony 2.5 vs Laravel 5. Я трогал только Symfony 2.5 — очень понравился — после Symfony 1.4 как глоток свежего воздуха (для тех кто все еще думает переезжать ли с Symfony 1.4).
После симфони 2.4-2.5 пишу на ларавеле 4
из хорошего, что они прикрутили — очереди, хелперы связи Input и Session, разруливание обработчиков ошибок по типу параметра
из плохого — их орм, после доктрины как-то совсем не то, особенно миграции, обработка форм — тоже совсем совсем фигово.
очень огорчило кривое наследование шаблонов в blade — такой впечатление что контекста нет вообще, решить простейшую задачу отображения в цикле нужного шаблона в зависимости от типа я не смог — если эти шаблоны наследуются то секции не работают нормально.
из того что улучшили в 5 — наконец-то неймспейсы, дождались ну и наконец-то додумались экранировать в блейде по умолчанию, остальное раздражающее мелкое не убрали вроде.
с учетом того что кишки симфони торчат отовсюду, это называется хипстеры не осилили симфони, поэтому взяли то что осилили, а в пятой похоже осилили чуть больше.
Я не спорю что после какого-то там кодеигнайтера ларавел будет мегакрут, но после симфони это такой шажок назад.
Полезного на несколько бандлов, а вот убрали побольше
из хорошего, что они прикрутили — очереди, хелперы связи Input и Session, разруливание обработчиков ошибок по типу параметра
из плохого — их орм, после доктрины как-то совсем не то, особенно миграции, обработка форм — тоже совсем совсем фигово.
очень огорчило кривое наследование шаблонов в blade — такой впечатление что контекста нет вообще, решить простейшую задачу отображения в цикле нужного шаблона в зависимости от типа я не смог — если эти шаблоны наследуются то секции не работают нормально.
из того что улучшили в 5 — наконец-то неймспейсы, дождались ну и наконец-то додумались экранировать в блейде по умолчанию, остальное раздражающее мелкое не убрали вроде.
с учетом того что кишки симфони торчат отовсюду, это называется хипстеры не осилили симфони, поэтому взяли то что осилили, а в пятой похоже осилили чуть больше.
Я не спорю что после какого-то там кодеигнайтера ларавел будет мегакрут, но после симфони это такой шажок назад.
Полезного на несколько бандлов, а вот убрали побольше
Спасибо за развернутый ответ!
За это время я тоже потрогал Laravel 4 — понравилось возникшее чувство простоты и понятности. Symfony 2.5 при всех ее плюсах не блещет простотой, иногда даже через чур сложна и требуется время, чтобы вникнуть в предоставляемые ею концепции.
Для себя я пока остановился на следующем:
— для своих не больших проектов и/или проектов для души беру Laravel 4 (для новых проектов Laravel 5);
— для долгоиграющих рабочих проектов беру Symfony 2.6.
За это время я тоже потрогал Laravel 4 — понравилось возникшее чувство простоты и понятности. Symfony 2.5 при всех ее плюсах не блещет простотой, иногда даже через чур сложна и требуется время, чтобы вникнуть в предоставляемые ею концепции.
Для себя я пока остановился на следующем:
— для своих не больших проектов и/или проектов для души беру Laravel 4 (для новых проектов Laravel 5);
— для долгоиграющих рабочих проектов беру Symfony 2.6.
с учетом того что кишки симфони торчат отовсюду, это называется хипстеры не осилили симфони, поэтому взяли то что осилили, а в пятой похоже осилили чуть больше.
Это просто отличное сравнение, лучше бы выразиться я не смог. В точку!
Вообще кесарю кесарево. Ведь фреймворк изначально был заточен под rest. У нас используется еще с третьей версии. Используется в основном для бекенда разных сервисов. Он именно еще тогда зацепил простотой. С выходом 4-ки пришлось перестроиться, но по прежнему писать rest api было просто и быстро, да и код получался элегантный. Судя по обзору 5-ка выглядит как логичное продолжение 4-ки, при этом с некоторыми почти фундаментальными изменениями. Опять придется пересроиться. Опять же структура файлов, она может и удобная, но переключаться между старыми проектами и новыми, мне видится, будет не очень удобно. Но это неизбежные потери.
Еще одна замечательная вещь, которую вы не упомянули говоря о роутинге, это возможность указывать пути в php аннотациях. Эта штука мне понравилась в Symfony2, только в случаее с Ларой придется еще и запустить комманду в артисан, что бы сгенерировался файл роутинга, но все же это уже радует и упрощает разработку. Тут Мэтт Стауффер описывает как раз таки аннотации, так же есть еще несколько статей по новым фитчам в Laravel 5
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Что нового в Laravel 5?