Laravel Чем вызван взрывной интерес к Лярве?

[Sender]

> ЗЫ. У похапешечки на тех же трендсах - совсем плохо. Звездный час был в 2005 и с тех пор равномерно катится вниз...
Нормальное явление. Стек мобильных технологий вытесняет. Java, C++ примерно тот же график.

По laravel - скорее всего эффект низкой базы. То что на overflow много вопросов - не показатель. У symfony хорошая документация, листы рассылки, github и т.п. В общем надо смотреть стек, который в вакансиях указывают, остальное от лукавого.

имхо

 

[keltanas]

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

Сравним код для 2х фреймворков:

Route::get('/', function()
{
    return View::make('greeting', ['name' => 'Taylor']);
});

и

$app->get('/', function () use ($app) {
    return $app['twig']->render('hello.twig', ['name' => 'Taylor']);
});

Если, как работает второй вариант очевидно и понятно всем, то первый вариант - это статическая магия и большинству тех, которые будут делать на этом сайты не понятная.
Зачем в наше не простое время применять такие не очевидные подходы, и как этим можно пользоваться, когда есть вариант 2, мне трудно понять.
Но, это ИМХО. В конце концов каждый сам определяет свою ориентацию и вероисповедание ))

 

[AmdY]

во втором варианте уже завязка на твиг, а в первом отрендерится шаблон который есть (.php, .blade.php, .twig). Автокомплит во втором варианте тоже не сработает.
код можно переписать, никто не навязывает пользование алиасами, они для DI и простоты моков

Route::get('/', function(View $view, User $user)
{
    return $view->make('greeting', ['name' => $user->name]);
});

Здесь DI и автокомплит

Laravel не менее функциональный и гибкий нежели симфони, просто все паттерны скрыты под капотом и сладким синтаксисом.

 

[флоппик]

Если, как работает второй вариант очевидно и понятно всем, то первый вариант - это статическая магия

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

 

[fixxxer]

Зачем в наше не простое время применять такие не очевидные подходы

Да можно и через честный DI делать, AmdY уже написал. С алиасами просто компактнее. Алиасы спорны с точки зрения "чистоты" ООП, но удобнее на практике.
Касаемо очевидности - предполагается, что тот, кто пишет на фреймворке, сначала ознакомился с мануалом.
Проблему автокомплита решает barryvdh/laravel-ide-helper.

 

[Absinthe]

Проблему автокомплита решает barryvdh/laravel-ide-helper.

IDE должна сама запускать это при модификации файлов, которые влияют на результат этой команды.

 

[fixxxer]

В сторме это делается через watchers вполне. Конечно, будут лишние холостые прогоны, но меня это не особо беспокоит.

 

[hell0w0rd]

AmdY,

во втором варианте уже завязка на твиг

Это уже придирки. В silex - это service locator, можешь templating из симфони взять и вкрутить.
Кстати благодаря этому я как-то раз делал интересную вещь - класс контроллера принимает Silex\Application и реализует ArrayAccess, проксируя все get/set-ы к $app. Затем в контроллере подключаем нужные трейты и имеем любую функциональность

 

[grigori]

думаете, вопроса соответствия PSR удастся избежать?

 

[Linker]

PHP-FIG вам

 

[fixxxer]

Свой код прекрасно пишется по psr, а что там внутри - это личные заморочки автора, он уперся. Вообще личные заморочки и баранья упертость у авторов популярных фреймворков почему-то типичны

 

[grigori]

к сожалению, это так

 

[slider23]

"Чем заслужил свою популярность Laravel?" http://toster.ru/answer?answer_id=280561#answers_list

 

[Вурдалак]

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

 

[флоппик]

зависимость от фреймворка, буэ.

ОМГ, приложение зависит от его кода!

 

[Вурдалак]

ОМГ, приложение зависит от его кода!

https://speakerdeck.com/jakzal/decoupling-from-the-framework — рекомендую.

 

[fixxxer]

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

Понимаю претензии в контексте govnokod-proof, но это не проблема laravel

 

[hell0w0rd]

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

 

[Вурдалак]

никто не заставляет пользоваться фасадами везде.

Не-не-не. Правильнее сказать: «никто не запрещает».

 

[fixxxer]

Запрещать может code style проекта или ревьюер. Так-то и $_GET и global никто не запрещает, ога.