Как стать автором
Поиск
Профиль
Обновить

Комментарии 90

Уже давольно давно присматриваюсь к этому фреймворку, и вот сейчас, наконец, появилась возможность сделать на нём новый проект. Новая версия как нельзя кстати!
Всего голосов 4: ↑4 и ↓0 +4
Она немного сырая еще (учитывая, что релиза не было), но начинать смотреть ее очень стоит.
Это не тот фреймворк, который в ближайшее время может быть заброшен и прекратить развитие =)
Комментарий пока не оценивали 0
Думаю, что пока мы будем пилить проект, он уже успеет релизнуться
Комментарий пока не оценивали 0
Я бы тоже не советовал на 5-ке делать что-то серьезное. Надо немного подождать. Помнится 4-ка стала более менее юзабельной к 4.1
Комментарий пока не оценивали 0
Отличный пост, большое спасибо!
Всего голосов 10: ↑4 и ↓6 -2
Остается только добавить, что релиз пятой версии будет в ноябре :)
Комментарий пока не оценивали 0
В этой статье я хотел бы написать о новой версии Laravel, официальный релиз которой состоится в ноябре, но скачать и попробовать которую можно уже сейчас через Composer.

Уже было в статье :)
Всего голосов 1: ↑1 и ↓0 +1
Оу, тогда прошу извинить, пробежался по посту по диагонали, не заметил :)
Всего голосов 1: ↑1 и ↓0 +1
Очень зря, отлично написанная статья — узнал много нового даже о 4ке, хотя статья про 5ку. =)
Всего голосов 1: ↑1 и ↓0 +1
Не спорю, просто все это про пятерку узнал буквально на днях собирая по кусочкам то тут, то там :)
Комментарий пока не оценивали 0
Все же, учитывая частоту коммитов в github.com/laravel/laravel/commits/develop стоит предупредить народ, что начинать проекты на пятерке сейчас не стоит, даже к бете может все очень сильно измениться внутри.
Всего голосов 2: ↑2 и ↓0 +2
Вообще могу конечно упомянуть это в статье, но вот сам Laravel уже перевел свой сайт на 5 версию.
twitter.com/taylorotwell/status/514090413414572032
Всего голосов 1: ↑1 и ↓0 +1
НЛО прилетело и опубликовало эту надпись здесь
Спасибо за прекрасную статью, прочитал на одном дыхании. Пишите еще.
А не присматривались к Yii2, RC выходит через пару дней, он тоже хорош, а автокомплит в PhpStorm просто волшебный.
Пока метаюсь между ними и пытаюсь понять, что же удобней, но коммьюнити у laravel все таки помощнее, одни только laracasts чего стоят.
Всего голосов 4: ↑4 и ↓0 +4
Yii 2, имхо, стоит смотреть тем, кто уже привык к первой версии, всем же, кто присматривается к совершенно новому для себя фреймворку — я бы посоветовал именно Laravel.
Всего голосов 5: ↑3 и ↓2 +1
У Laravel в PhpStorm тоже есть автокомплит, на laracasts есть 2ух минутный урок где объясняется как это сделать, это 15ый из бесплатной серии уроков по PhpStorm. Используется Laravel IDE Helper и он подходит не только под PhpStorm, но и под другие IDE (лично проверял только на PhpStorm).
Всего голосов 1: ↑1 и ↓0 +1
У Laravel есть автокомплит, никто не спорит. Но вы посмотрите на автокомплит в Yii2, а потом на Laravel. Все станет ясно.
Всего голосов 1: ↑1 и ↓0 +1
А в чем разница, если не секрет? Чем в Yii лучше?
Комментарий пока не оценивали 0
Присоединяюсь к вопросу, в чём отличие?

*При наличии "barryvdh/laravel-ide-helper": "1.*", в composer.json у Laravel =)
Комментарий пока не оценивали 0
Попробовал оба (yii2 и laravel 4).
Я остановился на Yii2. Главная причина — более удобная работа с формами и валидация в моделях (в ларавел нет встроенной валидации моделей).
А так — оба фреймворка чем то похожи. Даже ларавеловские фасады похожи на компоненты yii.
Ну и такие фишки у Yii, как gii (для генерации кода), Grid, DataProvider, RBAC из коробки и тд — после того как поработаешь с ними, чуствуешь, что чего не хватает в других фреймворках.

Всего голосов 2: ↑2 и ↓0 +2
Валидацию специально вынесли отдельно, дабы не перегружать модели. До этого все далали по разному, как правильно заметили в статье. В новой версии с импрувнутым валидатором веротяно процесс как-то унифицируется. По поводу фишек типа gii и прочих, то тут тоже умышленое избегание перегрузки функционалом. Все это есть, все это активно используется, но вынесено в отдельные компоненты. Composer в помощь
Комментарий пока не оценивали 0
В том то и дело, что речь об удобстве. Валидация внутри моделей очень удобна. 

$model->load($_POST);
if(!$model->save()){
 ...
}


Я только ради этого функциоанала остался на yii

А по поводу composer — так он подключается везде, в том числе и в yii2. Другое дело, что в yii есть из коробки работа с RBAC c хорошей описанной документацией, а в ларавел надо что-то искать, подключать, разбираться. А DataProvider? Я вообще больше нигде не встречал ничего похожего (ну кроме views в друпале). Лично мне кажется, что скорость разработки благодаря встроенным компонентам в yii повышается.

Вот что действительно удобно, чего мне не хватает — это мощное консольное приложение в Laravel.
Ну и Queues. Хотя, поддержку очередей можно уже доустановить через тот же composer.
Комментарий пока не оценивали 0
просто добавляли метод в модель, например так

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);
  }


можно навесить на констурктор модели и тогда получим как примерно тоже самое, как у тебя в примере.
Такая фривольность, очевидно, имеет свои минусы, но именно поэтому мне фреймворк и понравился. Чувствуется, что не ты работаешь на фреймворк, а фреймворк рабтает на тебя.
Комментарий пока не оценивали 0
В том то и дело, что нужно добавлять, что-то доделывать. А тут — не сохранилось, показываем почему не сохранилось (передаем в шаблон эту модель, в которой все свойства уже заполнены, все ошибки уже прописаны). Более того, yii (что 1й что 2й) умеет делать ajax валидацию. Т.е. работа с формами и моделью сводится к выводу input поля и попытки сохранить данные. Все остальное фреймворк сделает сам. Если не сохранилось — сам покажет и заполнит форму, покажет ошибки и тд. Но, валидация модели ещё хороша тем, что делается только 1 раз и забываешь про это. Т.е. если мы хотим заполнить данные модели вручную (не на основе данных, которые пришли из броузера, а, допустим, при выполнении какой-то фоновой задачи, воркера 
$model = new Post();
$model->a = 'a';
$model->b = 123;
$model->save();

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

На счет кто на кого работает — это уже довольно субъективно :)
Комментарий пока не оценивали 0
В yii все хорошо, пока не понадобится вывести, например, дату для редактирования (в бд метка времени, а в форме — строка) или любые другие поля которые в редактируемом виде отличаются от того что хранится в базе. Вот тогда начинаются всякие извращения (использую самописное поведение для прозрачной конвертации между оригинальным полем и фейковым полей строкой).
Комментарий пока не оценивали 0
в Yii2 встроенный мощный форматтер на базе intl
Комментарий пока не оценивали 0
В L4 на базе Carbon
Комментарий пока не оценивали 0
carbon — всего лишь обертка над DateTime, добавляющая сахар.
Комментарий пока не оценивали 0
ага, и в 90% случаев достаточно 10% методов Карбона
Комментарий пока не оценивали 0
форматтер — не обертка над DateTime. Полный контроль над обработкой и выводом даты с учетом локали. Вообще некорректно сравнивать Carbon и Formatter.
Комментарий пока не оценивали 0
Да и ладно, все равно я его люблю не за это
Комментарий пока не оценивали 0
Я не про форматирование говорил: пусть есть модель с полем date, которое хранится в бд в виде метки времени, пользователь его вводит в виде «dd.MM.yyyy HH:mm», как его нормально вывести, валидировать и сохранить? Первое что приходит на ум и что везде гуглится это повесить валидатор на `date` и потом где-то перед сохранением модели добавить конвертацию этой строки обратно в метку времени. Вот только это чрезвычайно кривое решение, потому что в одно время поле хранит строку, а в другое — число => никогда не знаешь что там окажется…

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

Или в yii 2 эта проблема уже решена?
Комментарий пока не оценивали 0
не могу точно сказать. Есть глобальные настройки для вывода дат.
В вашем случае не надо ничего фейкового делать, достаточно написать поведение на два события: afterFind и beforeValidate, с двумя аргументами outputFormat и inputFormat.
Комментарий пока не оценивали 0
И потом поиметь проблем в различных местах приложения когда в поле вместо метки времени окажется строка (или наоборот)? Нет, спасибо, уже сталкивался. Поэтому теперь всегда использую отдельные поля для отформатированных значений.
Комментарий пока не оценивали 0
почему вместо метки времени придет строка? дайте кейс.
Комментарий пока не оценивали 0
Если я не ошибаюсь, то вы имели в виде что-то наподобие?
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 только начинаешь работать).
Всего голосов 1: ↑1 и ↓0 +1
да, конечно нужно еще добавить третье событие afterSave
и нет, я не имел в виду такой прямой подход — я имел в виду поведение (behavior)
Комментарий пока не оценивали 0
Только на afterValidate наверное (а этого кстати нет во многих примерах которые можно нагуглить). Но, в любом случае, с двумя полями получается гораздо проще/лучше, тем более внутри приложения метка времени нужна чаще чем то, что видит пользователь при выводе/редактировании (собственно у меня форматированная дата только им и используется, в коде везде числа).
Комментарий пока не оценивали 0
нет, после валидации дату надо сохранить, и только потом опять ее привести к читаемому виду.
С двумя полями получается грязнее, но да, возможно так удобнее, если метку еще где-то использовать.
Комментарий пока не оценивали 0
после валидации дату надо сохранить

Ага, точно, но тогда если просто вызвать validate() получим туже проблему.

с двумя полями получается грязнее

Кода немного больше (если конечно через поведение делать), но он прозрачный.
Комментарий пока не оценивали 0
В yii все модели наследуются от Component.
Поэтому можно использовать встроенные геттеры и сеттеры.

Допустим в базе хранится в поле created_at = 1412676897;
В модели пишем так:
public function getCreated(){
  return date("Y-m-d H:i", $this->created_at);
}


Ну и потом используем в шаблонах 
echo $model->created;


— Опа, решил ответить после обеда и страницу не обновил, а тут выше целая дискуссия развернулась.
Комментарий пока не оценивали 0
Это всё понятно, но нужен еще 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();
    }
}
Комментарий пока не оценивали 0
выше я вам поведение и предложил. Пишется за 5 минут, проблем никаких.
Комментарий пока не оценивали 0
А может кто-то сказать чем лучше yii 2? Со стороны смотрю на это чудо, и кажется что это тот же yii.
Комментарий пока не оценивали 0
Всего голосов 3: ↑3 и ↓0 +3
А я вот так делаю =-)

propel diff
propel migrate
propel model:build
Комментарий пока не оценивали 0
В варианте с yii ошибка, $this->batchInsert('{{%lang}}', ...)
А в примере ларавел есть один большой подводный камень. Если в будущем изменится название таблицы lang, миграция с нуля не сработает. Т.к. в момент выполнения этого шага у нас имеется таблица lang, а в коде модели будет прописана таблица language, например.

Имхо, гибкость миграций yii доставляет больше, т.к. свойства полей описываются привычным sql синтаксисом, и можно точно сказать какое поле будет создано — varchar(255) или text, например.
Всего голосов 2: ↑2 и ↓0 +2
Согласен, по-этому там следует Lang::create заменить на DB::table('lang')->insert.

Это же просто пример =)
Комментарий пока не оценивали 0
Я думаю, что вы хотели показать какие классные краткие миграции у L4. Но вот из вашего примера, я совершенно не понимаю, какие поля разрешают NULL, какие — нет, какая длина строковых ключей, какой engine, какая кодировка и т.п. Наверняка это настраивается, но с дополнительными параметрами окажется что пример будет не таким уж и кратким.
Всего голосов 1: ↑1 и ↓0 +1
Умолчания есть везде :) Если писать полностью, будет выходить что-то вроде
$t->string('remember_token', 100)->nullable(); 



$t->string('remember_token', 100)->default('1111');


По-моему, тоже достаточно кратко.
Комментарий пока не оценивали 0
Ну посмотрите хотя бы на AR, на автозагрузку, все стало гораздо удобнее.
Всего голосов 2: ↑2 и ↓0 +2
Еще раз: ни единая строчка кода из метода store не будет исполнена, если форма не проходит валидацию.

Как будет реагировать если форма не приходит валидацию?
Комментарий пока не оценивали 0
За это отвечает метод Illuminate\Foundation\Http\FormRequest@response.
Если ajax запрос, отдаст json с ошибками и кодом 422, а если нет — редиректит назад со всеми ошибками валидации.
Всего голосов 2: ↑2 и ↓0 +2
А где можно почитать про существенные отличия от других популярных фреймворков?
Я недавно тоже попробовал Laravel, почти всё понравилось, но в целом достаточно всё похоже на другие фреймворки, хотя конечно я глубоко его не изучал, прошелся по основным функциям — конфигурация окружений, MVC, работа с БД, авторизация…
Комментарий пока не оценивали 0
Ну, сейчас многие фреймворки в общем очень похожи. А вообще, самый лучший способ, я считаю — почитать документацию. Там всё очень понятно описано.
Комментарий пока не оценивали 0
Я бы еще порекомендовал посмотреть эти скринкасты, там все довольно подробно рассказано про все нововведения :)
Комментарий пока не оценивали 0
Я не считаю себя гуру в php и фреймворках. До этого пару раз работал с первым и вторым зендом, бессмертным битриксом, сталкивался с Yii и Symphony, изобретал велосипеды сам, но каждый раз у меня оставалось смутное чувство неудовлетворенности.

Переходите уже на Rails, будет меньше отрицательных смутных чувств :)
Всего голосов 11: ↑3 и ↓8 -5
У нас на работе рельсы (работаю фронтэндером). Нет уж, спасибо, лучше уж синатру, а ещё лучше ларавель. =)
Всего голосов 2: ↑1 и ↓1 0
Рельсы написаны человеком для человеков (-:
Реально на руби и рельсах приятно писать…
Всего голосов 2: ↑1 и ↓1 0
Мог бы стать идеальным фреймверком если бы не статические вызовы ((
Всего голосов 5: ↑0 и ↓5 -5
Решение: Удалить алиасы из app/config/app.php и использовать внутренности напрямую. Или из внутренностей регистри приложения, например:
app('auth')->user;
// вместо
Auth::user;
Всего голосов 1: ↑1 и ↓0 +1
Хм, а это не плохая мысль, надо будет внимательнее изучить такую возможность.
Комментарий пока не оценивали 0
Предлагаю попробовать посмотреть как запускается L4 — это очень много скажет о том, как он устроен и как с ним можно извращаться =)

Наверное достаточно будет разобраться с этим хелпером: github.com/laravel/framework/blob/4.2/src/Illuminate/Foundation/start.php
Комментарий пока не оценивали 0
Посмотрел код, получается на самом деле все статические вызовы, это всего лишь обвертка. И по хорошему можно с таким же успехом все завернуть в свою обвертку, и работать с нормальным ооп =D
Всего голосов 1: ↑1 и ↓0 +1
Тоже вначале сильно смутило что слишком много статики, но почти вся статика это по сути фасады и на самом деле они проксят запрос к объекту внутри App. Т.е. на самом деле можно все их дергать прямо через App, но во вьюхах реально удобно именно через фасад — например при генерации форм {{ Form::open… весьма удобно
Комментарий пока не оценивали 0
Статические вызовы — это просто сахарок для контейнера. laravel.com/docs/4.2/facades

Т.е. изначально есть
$app->make('cache')->get('key');

для него создается фасад Cache с обработчиком __callStatic(), чтобы можно было писать так
Cache::get('key')

Хотя, конечно, все равно как-то криво. DI тем и хорош, что по описанию конструктора сразу понятно, какие сервисы там используются. А так понатыкают вызовы этих фасадов по всему коду, и выясняется, что класс завязан на 20+ других классов, хотя можно обойтись 2-3.
Всего голосов 1: ↑1 и ↓0 +1
Нет там никаких статических вызовов :)) Честное слово, этот вопрос в интернете задает каждый второй, кто только увидел Laravel.
Комментарий пока не оценивали 0
С Laravel не работал, но то обстоятельство что у них похоже вообще больше нет публичного списка багов (или есть? где?) и единственный способ запостить баг это использование liferaft, очень сильно способствует тому чтобы о нем просто забыть…

Активные разработчики, с багами все на самом деле печально или я ошибаюсь?
Всего голосов 5: ↑5 и ↓0 +5
Работаю с Laravel еще с 3-ей версии. За всё это время только в одной версии был обнаружен критический баг, который на следующий день уже был исправлен.
Поэтому в стабильных версиях всё нормально. А в dev версиях — бывают, конечно.
Всего голосов 2: ↑1 и ↓1 0
Поэтому в стабильных версиях всё нормально.

Я иногда работаю с yii 1.x, критичных багов там вроде давно уже нет, но регулярно возникают мелкие проблемы, например, из последнего: были проблемы с CGridView при включении history переставал работать .update что полностью ломало поиск. Минут через 15 был найден соответствующий баг на гитхабе (#2017, он до сих пор открыт) и импортирован в проект. Если бы не трекер, пришлось бы потратить кучу времени для решения этой проблемы…

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

Похоже что теперь вы о нем узнаете в лучшем случае после выхода нового релиза (у того же yii это может очень много времени занимать).
Всего голосов 1: ↑1 и ↓0 +1
Ну, вот как-то не появляются мелкие проблемы. Ну, или они моментально фиксятся, что я даже заметить не успеваю.

Похоже что теперь вы о нем узнаете в лучшем случае после выхода нового релиза (у того же yii это может очень много времени занимать).

Я читаю твиттер laravel и Тэйлора. Если что-то критическое появляется, информация об этом есть в твиттере.
Всего голосов 2: ↑1 и ↓1 0
Тейлор сам на своём сайте ещё пишет, почему он решил что-то использовать и как это по его мнению правильно делать.
taylorotwell.com/
Читаю тоже по утрам. Думаешь это баг, а это фича :)
Комментарий пока не оценивали 0
А как обстоят дела со скоростью у Laravel по сравнению с Yii2?
В своё время сравнивал его ещё с первым Yii на «hello world», так Laravel тогда сильно разочаровал.
Комментарий пока не оценивали 0
Честно говоря, мне уже очень давно не попадалось объективных тестов скорости фреймворков. Сейчас все больше развлекаются, тестируя приложения «Hello, world» либо меряя, что быстрее — echo или print ;) А вам?
Комментарий пока не оценивали 0
«Hello world» позволяет прикинуть оверхед фреймворка.
Что касается бенчмарков, то на techempower.com кое-что есть. К сожалению Yii там отсутствует.
Комментарий пока не оценивали 0
Как всегда зависит от задач.
Очевидные тормоза в Laravel'e это фасады. Магия, магия.
DIC сам по себе достаточно прост и не тормознутный (разве что сам DI через рефлексию может напрягать, особенно с учетом изменений в 5ой версии), заросы через Symfony'вский HttpRequest идут.
Eloquent быстрее чем Doctrine, но попроще.
Ну а вообще, стандартный ответ — нужна скорость? не пишите на PHP, либо переходите на экзотику типа HHVM / Phalcon / ReactPHP.
Всего голосов 1: ↑0 и ↓1 -1
HHVM уже не экзотика. Например, Yii 2.0 на нём бегает отлично.
Всего голосов 2: ↑1 и ↓1 0
Если HHVM не экзотика — предлагаю привести в пример обычный дешёвенький хостинг с поддержкой HHVM ;)
Комментарий пока не оценивали 0
Менее именитые продают подобные 5$ машинки по 2—3$.
Комментарий пока не оценивали 0
Symphony


Symfony же?
Комментарий пока не оценивали 0
Интересная статья. Особенно понравилось, что автор сначала говорит как там все хорошо и ему нравится Laravel, а потом описывает, что пятая версия решает много «костылей», делавшихся в четверке.

Автору спасибо — прочитал на одном дыхании!

Интересует мнение разработчиков на тему Symfony 2.5 vs Laravel 5. Я трогал только Symfony 2.5 — очень понравился — после Symfony 1.4 как глоток свежего воздуха (для тех кто все еще думает переезжать ли с Symfony 1.4).
Комментарий пока не оценивали 0
После симфони 2.4-2.5 пишу на ларавеле 4

из хорошего, что они прикрутили — очереди, хелперы связи Input и Session, разруливание обработчиков ошибок по типу параметра

из плохого — их орм, после доктрины как-то совсем не то, особенно миграции, обработка форм — тоже совсем совсем фигово.

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

из того что улучшили в 5 — наконец-то неймспейсы, дождались ну и наконец-то додумались экранировать в блейде по умолчанию, остальное раздражающее мелкое не убрали вроде.

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

Я не спорю что после какого-то там кодеигнайтера ларавел будет мегакрут, но после симфони это такой шажок назад.
Полезного на несколько бандлов, а вот убрали побольше
Комментарий пока не оценивали 0
Спасибо за развернутый ответ!

За это время я тоже потрогал Laravel 4 — понравилось возникшее чувство простоты и понятности. Symfony 2.5 при всех ее плюсах не блещет простотой, иногда даже через чур сложна и требуется время, чтобы вникнуть в предоставляемые ею концепции.

Для себя я пока остановился на следующем:
— для своих не больших проектов и/или проектов для души беру Laravel 4 (для новых проектов Laravel 5);
— для долгоиграющих рабочих проектов беру Symfony 2.6.
Комментарий пока не оценивали 0
с учетом того что кишки симфони торчат отовсюду, это называется хипстеры не осилили симфони, поэтому взяли то что осилили, а в пятой похоже осилили чуть больше.

Это просто отличное сравнение, лучше бы выразиться я не смог. В точку!
Комментарий пока не оценивали 0
НЛО прилетело и опубликовало эту надпись здесь
Вообще кесарю кесарево. Ведь фреймворк изначально был заточен под rest. У нас используется еще с третьей версии. Используется в основном для бекенда разных сервисов. Он именно еще тогда зацепил простотой. С выходом 4-ки пришлось перестроиться, но по прежнему писать rest api было просто и быстро, да и код получался элегантный. Судя по обзору 5-ка выглядит как логичное продолжение 4-ки, при этом с некоторыми почти фундаментальными изменениями. Опять придется пересроиться. Опять же структура файлов, она может и удобная, но переключаться между старыми проектами и новыми, мне видится, будет не очень удобно. Но это неизбежные потери.
Комментарий пока не оценивали 0
Еще одна замечательная вещь, которую вы не упомянули говоря о роутинге, это возможность указывать пути в php аннотациях. Эта штука мне понравилась в Symfony2, только в случаее с Ларой придется еще и запустить комманду в артисан, что бы сгенерировался файл роутинга, но все же это уже радует и упрощает разработку. Тут Мэтт Стауффер описывает как раз таки аннотации, так же есть еще несколько статей по новым фитчам в Laravel 5
Комментарий пока не оценивали 0
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Ваш аккаунт

Разделы

Информация

Услуги

Техническая поддержка Вернуться на старую версию
© 2006–2023, Habr