Меню
Что нового?

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

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

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

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

Сравним код для 2х фреймворков:
PHP: 
Route::get('/', function()
{
    return View::make('greeting', ['name' => 'Taylor']);
});
и
PHP: 
$app->get('/', function () use ($app) {
    return $app['twig']->render('hello.twig', ['name' => 'Taylor']);
});

Если, как работает второй вариант очевидно и понятно всем, то первый вариант - это статическая магия и большинству тех, которые будут делать на этом сайты не понятная.
Зачем в наше не простое время применять такие не очевидные подходы, и как этим можно пользоваться, когда есть вариант 2, мне трудно понять.
Но, это ИМХО. В конце концов каждый сам определяет свою ориентацию и вероисповедание ))
 
во втором варианте уже завязка на твиг, а в первом отрендерится шаблон который есть (.php, .blade.php, .twig). Автокомплит во втором варианте тоже не сработает.
код можно переписать, никто не навязывает пользование алиасами, они для DI и простоты моков
PHP: 
Route::get('/', function(View $view, User $user)
{
    return $view->make('greeting', ['name' => $user->name]);
});
Здесь DI и автокомплит

Laravel не менее функциональный и гибкий нежели симфони, просто все паттерны скрыты под капотом и сладким синтаксисом.
 
keltanas написал(а):
Если, как работает второй вариант очевидно и понятно всем, то первый вариант - это статическая магия
Нажмите для раскрытия...
по моему, однофигственная статическая магия и там, и там, но при этом первый вариант читабельней на порядок.
 
Зачем в наше не простое время применять такие не очевидные подходы
Нажмите для раскрытия...
Да можно и через честный DI делать, AmdY уже написал. С алиасами просто компактнее. Алиасы спорны с точки зрения "чистоты" ООП, но удобнее на практике.
Касаемо очевидности - предполагается, что тот, кто пишет на фреймворке, сначала ознакомился с мануалом.
Проблему автокомплита решает barryvdh/laravel-ide-helper.
 
В сторме это делается через watchers вполне. Конечно, будут лишние холостые прогоны, но меня это не особо беспокоит.
 
AmdY,
во втором варианте уже завязка на твиг
Нажмите для раскрытия...
Это уже придирки. В silex - это service locator, можешь templating из симфони взять и вкрутить.
Кстати благодаря этому я как-то раз делал интересную вещь - класс контроллера принимает Silex\Application и реализует ArrayAccess, проксируя все get/set-ы к $app. Затем в контроллере подключаем нужные трейты и имеем любую функциональность:)
 
думаете, вопроса соответствия PSR удастся избежать? :)
 
Свой код прекрасно пишется по psr, а что там внутри - это личные заморочки автора, он уперся. Вообще личные заморочки и баранья упертость у авторов популярных фреймворков почему-то типичны ;)
 
Самое парадоксальное, что основная фича ваших фасадов и есть проблема. Получить инстанс легко откуда угодно, а это в свою очередь означает, что люди меньше задумываются о таких вещах, как декомпозиция, SRP, etc. Появляются скрытые зависимости, нет изолированности, зависимость от фреймворка, буэ.
 
никто не заставляет пользоваться фасадами везде. В коде, который пишется как независимая библиотека (или имеет шансы стать таковой), все передается через конструктор или сеттеры (а вот на саму эту библиотеку потом прекрасно навешивается сервис-провайдер и, по желанию, фасад). А в коде логики конкретного приложения, который тупо решает существующую задачу здесь и сейчас - самое то.

Понимаю претензии в контексте govnokod-proof, но это не проблема laravel :)
 
Вурдалак, с одной стороны все так, с другой инжектить TemplateEngine внутри контроллера, если ты не пишешь FosUserBundle кажется мне глупостью, в условиях реального приложения, а не абстрактной библиотеки под все случаи жизни.
 
  • Like
Реакции: AmdY
Запрещать может code style проекта или ревьюер. Так-то и $_GET и global никто не запрещает, ога.
 
Войдите или зарегистрируйтесь для ответа.
Сверху