Comments 93
Так, на одном проекте 5.1 и как с нее переходить на 5.4 я уже ума не приложу. Работы явно не на 1 день. А ведь поддержка LTS 5.1 прекращается уже в июне 2017 года…
Тейлор отказался от идеи LTS в принципе, насколько я знаю. Так что 5.1 — последняя LTS версия.
А как же 5.5? https://laravel-news.com/laravel-release-process Откуда подобная инфа про отказ от новых LTS?
Хм, значит, не правильно понял. :)
@Andy_V nah i don't think so. LTS is sort of an anti-pattern IMO.
— Taylor Otwell (@taylorotwell) December 16, 2016
Да.
Ну с одной стороны я согласен, LTS билды мешают сосредоточиться на постоянном улучшении кодовой базы в новых версиях, а так же поощряют пользователей оставаться на "старом добром работает — не трожь" и как следствие — дальнейшее обновление (после окончания поддержки LTS и появления нового) может окончиться болью.
Но с другой стороны LTS необходим, т.к. зачастую в современной практике важнее стартануть продукт и навешать свистоперделок, вместо полноценной поддержки и обновления оного. Заодно и для крупных вендоров (ну т.е. компаний) невозможно без LTS обходиться.
Так что это палка о двух концах. Имхо, стоит выпускать LTS но с менее продолжительным жизненным циклом и чуть большим количеством оных.
Ещё вот это порадовало:
@GLStephen @Andy_V we don't make bc breaks in patch versions
— Taylor Otwell (@taylorotwell) December 17, 2016
Он вообще такой интересный.
Вот тут можно проследить интересную логику: https://twitter.com/search?f=tweets&vertical=default&q=LTS%20from%3Ataylorotwell&src=typd
LTS is sort of an anti-pattern IMO.
I am not a fan of LTS in general. Prefer people take a couple days per year to stay updated
А до этого:
Forge currently designed for 14.04 LTS… will update to 16.04 LTS when its available
А чего ж не 14.10, 15.04, 15.10? Хорошо же несколько дней в году тратить на обновления! Быть на острие! Тем более когда LTS — антипаттерн!
Охренеть.
IMHO, в Вашем случае лучше всего дождаться поддержки Совой новой версии Laravel и только тогда апгрейдиться, чем делать это вслепую.
На простых проектах обновления протекают достаточно безболезненно — сел в локомотив и поехал дальше.
Поэтому приходится балансировать между скоростью разработки и поддержанием версий в актуальном состоянии. Если бы админка писалась полностью под проект без всяких CRUD — мы бы уже давно обновились. Но вы же должны понимать, что на такой проект потребуется несколько больше времени…
Возьмем еще один пример: laravelrus/localized-carbon. Отличный компонент, думаю многие им пользуются. Но увы, без вот этого патча локомотив не тронется даже в рамках 5.1 версии. Или вы предлагаете вообще все писать самостоятельно?
Есть в том числе и модалки со вкладками и есть отдельная Модерка на лицевой странице сайта, на тех же контроллерах. Разница, как мне кажется, только в выборе пути развития проекта. Вы пошли одним путём — мы пошли другим (возможно более трудным).
Без LTS ларе не захватить вкусный корпоративный (и консервативный) сектор, так и останется хипстерской игрушкой.
Вот весь ларавель это костыли и подпорки вместо того чтобы чуток почитать сложные места документации симфони.
Наплодить столько кривых решений это надо уметь, но похоже сейчас markdown в письмах получает премию за самый кривой костыль.
Где-то есть нормальное сравнение фреймворков?
Интересно, они починили блейд?
https://habrahabr.ru/post/238017/#comment_8316215
Я не минусил, но сравнение совершенно неверное. Альтернатива блоков в симфони — это секции блейда. Для слотов же альтернатива в твиге — это macro, и то с большой натяжкой.
Ну ок, слоты — это embed + macro.
Просто сравнивать Blade с Twig крайне не корректно. Blade создан для разработчиков, как доп.возможности для php. А Twig — это абстракция над языком с полным разбором токенов, построением AST (могу заблуждаться в деталях, не все сырцы просматривал) и прочее-прочее.
Это как сравнивать Doctrine и Eloquent и вопрошать "зачем?!!11". Одно DataMapper, другое ActiveRecord. Разные подходы, идеи и цели.
Понятно, что будут пересечения в возможностях, но концепции разные.
Какой в симфони аналог Eloquent? Doctrine? так это отдельный продукт, а для Blade? Twig? Так и это другой продукт, может быть в симфони есть "фасады"? так такого там вообще нет. Может вам стоит разобраться в теме, а не делать пустые вбросы?
Ну фасады — это просто красивый способ избавиться от симфонийской сервис локации $container->get, так что можно сказать, что да, это аналог, только чуть более элегантный.
Для этого «красивого способа» уже приделали стандартный костыль, без которого вообще ад.
На вкус и цвет. Лично я против, как фасадов, так и сервис локации. Но. Автокомплит есть (достаточно плагин подключить или пакет поставить). А шансов ошибиться в алиасе или судорожно вспоминать какое у него там название, исследуя services.yml из десятков бандлов на порядок меньше. Плюс статический доступ к элементу контейнера на порядок повышает профитность REPL (это, признаться, единственное место где фасады нужны, имхо).
А шансов ошибиться в алиасе или судорожно вспоминать какое у него там название, исследуя services.yml из десятков бандлов на порядок меньше.
*конечно же я имел ввиду что шанс ошибиться выше, а не меньше. Опечатался.
Лично я против, как фасадов, так и сервис локации.
А что Вы используете? :)
Можно примеры, почему за и против? :)
Спасибо.
Опять та же самая ошибка (самая популярная, наверное) =)
Фасады, в контексте Laravel — это не статика. Это статический прокси на элемент (объект, не класс) контейнера. По-факту там совершенно пустой класс у которого есть лишь пометка-ссылка на элемент контейнера. Отсюда и моё сравнение с сервис-локацией, популярной раньше в симфони.
А кто говорит, что от этого ушли? Ядро Symfony до сих пор напичкано этим. Но это не значит что нет более профитных инструментов, которые появились в symfony 2.8 (намёк на автовайринг). С таким же успехом можно говорить: "вот вы отнаследовались от базового симфонёвого контроллера и… ну и т.д. ваши слова.)
Это просто значит, что это хоть и есть в ядре и хоть это облегчает порог входа, более того — даже в доках примеры есть (как в симфони, так и в ларке) но эти решения не есть истина в последней инстанции и грамотные разрабы всегда предпочтут DI сервис локации.
По-этому и говорю, что "популярной раньше", так же как были популярны раньше фасады в ларке. Просто удобных альтернатив не было.
В симфони этим тоже многие страдают, но только не через фасады, а через запрос контейнера, и вызова нужных сервисов уже внутри класса, а не через DI.
В ларке есть совершенно чудесный DI с инжектами как в конструктор, так и в методы. При этом, у каждого "фасада" есть интерфейс, который висит в Contracts. Как следствие
1) фасады, либо для тех, кто осознаёт риск, но иногда проще и профитнее их запилить, вместо создания тучи сервисных классов
2) либо для новичков, которые пока не изучили механизм внедрения и сам контейнер
С фасадами
public function some()
{
return \Config::get('some.any', 23);
}
С двойной диспатчеризацией
// RepositoryInterface == Illuminate\Illuminate\Contracts\Config\Repository
public function some(RepositoryInterface $config)
{
return $config->get('some.any', 23);
}
С инжектом в конструктор
public function __contruct(RepositoryInterface $config)
{
$this->config = $config; // А в методе some просто получаем объект
}
В случае 2 и 3 достаточно указать интерфейс — ларка сама всё пробросит (во отличие от симфони, где надо прописывать автовайринг и проч).
во отличие от симфони, где надо прописывать автовайринг и проч
* в отличии (очепятался, простите)
По сути: Это не плохо. Можно в любой момент увидеть что куда улетает, пробежавшись по конфигам (services.yml). Но это не так удобно. Т.е. и плюс большой и минус.
Вы правы, фасады это не статика. Это классический сервис-локатор.
И правильнее пример переписать так:
public function some()
{
return $this->serviceLocator->get('some.any', 23);
}
В этом нет ничего сильно криминального за исключением того, что это крайне сильно повышает связанность кода.
Также лично я никогда не понимал радостей внедрения зависимостей прямо в методы. Это несколько нелогично перемешивать зависимости (которые могут меняться, добавляться и убираться) и аргументы — нет стабильного интерфейса.
Ну я приводил пример с фасадом, чтобы потом привести два других примера "как от них отказаться и начать жить". Радость же с внедрениями в метод просты:
1) Облегчается инциализация объекта (уменьшается список зависимостей в конструкторе)
2) Видно какие зависимости требует сам класс, а какие сам метод — это крайне актуально при тестировании и на порядки его упрощает
3) Позволяет реализовывать факторные методы, вместо написания самой фектори
4) Просто в некоторых местах удобнее
Можно рассмотреть простой пример. Как работают консольные скрипты в симфони:
1) Если мы хотим использовать православный DI — добавляем инжект в конструктор нужных сервисов и радуемся.
НО:
а) Набертся штук 30 таких скриптов и старт консоли превратится в муку, особенно из дев. режима с пересбором контейнера по несколько секунд
б) Если мы решим что-то инициализировать в этом конструкторе (ну, допустим соединение к БД указать другое) — нужно помнить, что эта иницализация отразится на всех существующих скриптах в проекте
Вывод: Надо получать либо через сеттер, либо через сервис-локацию в методе execute. И то, и другое, объективно, не очень. Но живём.
Пример с Laravel приводить нужно с DI в метод выполнения скрипта, вместо конструктора?
Ну и да, никто не мешает НЕ ломать интерфейс, даже используя DD. Но согласен, есть такие места, где так не прокатывает в Laravel. Боль.
А ещё можно сделать так, чтобы в команде был сервис-локатор, из которого бы лениво подгружался единственный объект и выполнялся — вынести всю логику из команды. По факту, это будет то же самое, о чём сейчас и говорим в ларавеле. В данном случае сервис локатор будет выступать в роли фабрики — и не более.
Только одно дело — применять эти фасады (как и сервис-локаторы) в контроллерах и командах, а другое — погружать их куда-нибудь далеко-далеко в бизнес логику.
public function some()
{
return app('config')->get('some.any', 23);
}
А может в симфони фасады нафиг не нужны? Не задумывались над этим? В ларавеле они кстати тоже нафиг не нужны, потому что DI вполне нормальный, но нет, прикрутили.
Этот ваш ларавель уже оброс костылями для подключения доктрины, твига и до кучи хелперами для хоть какой-то подсветки этих ваших фасадов и элоквента.
Чем Eloquent плох? Можно конкретики? А то всё "кривой-кривой", а аргументов 0.
В Eloquent слишком много магии, из-за которых порой возникают очень странные ошибки, которые не мог предусмотреть сам создатель.
Вот например, что случилось после недавнего неожиданного обновления laravel 4.2: https://www.reddit.com/r/laravel/comments/5cgih9/too_much_magic_in_laravel/
Тейлор в итоге выпустил новую версию, где откатил эти изменения.
Также там много чего намешано, что нарушает принцип MVC. За примером далеко ходить не надо:
$users = DB::table('users')->paginate(15);
Если же появится желание использовать Eloquent отдельно от Laravel, придётся увидеть на первый взгляд странную инициализацию, т.к. выяснится, что для полной работы eloquent нужны illuminate события — на них завязаны события eloquent вроде saving и прочего. Кому-то, возможно, удобно отправлять и обрабатывать события ORM через менеджер событий вместе со всеми остальными событиями приложений. Но лично для меня это бардак.
Недавно я делал простенький проект — собирал из компонентов symfony и прочих библиотек и решил в качестве шаблонизатора использовать привычный blade. И я отказался от этой идеи, увидев сколько всего он за собой тянет, включая эти сраные события (видимо для обработки composer-ов) и хелперы Illuminate\Support, которые не будут работать у меня из-за отсутствтия остальных частей Laravel.
На самом деле и Eloquent очень даже удобен в использовании (особенно конструктор запросов), но надо иметь ввиду следующие факты:
- Много магии, которая порой выстреливает в разработчика.
- Порой нарушаются принципы MVC и SOLID, что иногда мешает что-то сделать кастомное.
- Эти библиотеки крайне сильно завязаны на Laravel и не сильно то модульные.
Потому критика Eloquent вполне обоснована.
Скачались базовые компоненты симфони в зависимостях. К ним написаны обертки, которые по сути проксируют вызовы и добавляют фасады.
А потом у нас появляются статьи как прикрутить доктрину к ларавелю. Зачем нужно было использовать такой кривой велосипед как Eloquent?
Потом, посмотрите на папку Illuminate — там либо как в случае базовых компонентов идет extend Symfony либо творчество уровня студента —
Illuminate\Config например, конечно, симфоневый конфиг это сложно
роутинг — обвязка над симфоневым, и кеширование выдрано с мясом, а инициализация роутов вещь тяжелая
консоль — полностью притащена с симфони, но зачем-то сделана обертка.
> И почему markdown в письмах это костыль?
Вот на кой черт оно во фреймворке? Причем это blade, а потом то что получилось обрабатывается маркдауном, причем это прибито гвоздями, только в мейлере.
Для сравнения — как это сделано в симфини — есть банд https://github.com/symfony/swiftmailer-bundle который просто подключает библиотеку в контейнер и из него конфигурирует ее и ее плагины, после настройки метода отправки нужно просто вызвать container->get('mailer')->send($message) и передать ей объект сообщения, которому уже сам генеришь тело хоть твигом хоть маркдауном, хоть еще каким конвертором, который ставишь отдельно.
Симфони хорош для больших архитектур, где необходимы DI через конфиги и тп.
Идея Laravel быть гибкой и удобной. Идея Симфони быть правильной. Отсюда и ответ. Любому отпетому симфонисту вряд-ли понравится возможность "из коробки" иметь дополнительную зависимость.
При этом Laravel в результате получается на порядок удобнее:
// Symfony
public function listAction()
{
$repo = $this->container->get('doctrine')->getRepository(Some::class);
return new JsonResponse(['items' => $repo->findAll()]);
}
// Laravel
pubic function index(SomeRepositoryInterface $repo)
{
return $repo->findAll();
}
И зачастую даже грамотнее. А всякие замечания "прибито гвоздями" просто от незнания, т.к. Laravel местами гибче симфони.
Инжект параметров есть с 3.1 версии, причем не прибит гвоздями к роутеру, как в ларавеле, а реализован через события с помощью ресолверов и возможностью добавлять свои.
Вы простите когда удобство показываете хоть не на двухстрочных функциях это делайте, а то я же тоже могу взять бандлы для апи, там куча вкусностей развешено, а не только 2-3 стандартных преобразования.
А всякие замечания «прибито гвоздями» просто из-за того что посмотрел код мейлера.
Извините, но
$markdown = Container::getInstance()->make(Markdown::class);
да, именно так и нужно использовать контейнер!
Так что не только гвоздями прибито, но еще и суперклеем намазали.
Гибкий блин, удобный, особенно гибкий. Хомячки блин тупые, даже код не могут посмотреть той поделки на которой пишут.
гвоздями к роутеру, как в ларавеле
шта?
а реализован через события
Вместо того, что бы сделать по-нормально через контейнер. В ларке подобная схема работает не только для контроллеров, а для чего угодно. Т.к. DD реализован именно через него. Вспомните сколько автовайринг ожидали. И только к версии 3.2 (да ведь?) его наконец доделали до нормального состояния с резолвом из интерфейсов.
Вы простите когда удобство показываете хоть не на двухстрочных функциях это делайте, а то я же тоже могу взять бандлы для апи
А я не беру бандлы, я беру коробочную стандарт эдишн. В коробочной поставке симфони огрызок ещё тот, по-этому каждый проект потом превращается в фарш из JMS, Knp, Fos и прочей лабуды с вермишельками сонаты.
Гибкий блин, удобный, особенно гибкий. Хомячки блин тупые, даже код не могут посмотреть той поделки на которой пишут.
Мне жаль, что у меня, как симфониста есть подобные коллеги как вы.
В коробочной поставке симфони огрызок ещё тот, по-этому каждый проект потом превращается в фарш из JMS, Knp, Fos и прочей лабуды с вермишельками сонаты.
Мне жаль, что у меня, как симфониста есть подобные коллеги как вы.
На Simfony получается вермишельный код?
Его удобно поддерживать?
Почему вам тогда нравится Simfony? :)
На Simfony получается вермишельный код?
Его удобно поддерживать?
Почему вам тогда нравится Simfony? :)
Это утрированная ирония =)
- В Symfony ты собственноручно отстреливаешь себе ногу из пистолета
- В Laravel тебе мило предоставляется гранатомёт сразу "из коробки", чтобы наверняка
P.S.
- В Yii это небольшой виджет-танк на JQuery
</irony>
В документации Ларавеля указано в требованиях
PHP >= 5.6.4
https://laravel.com/docs/5.4
PHP 5.6.4 — это, что за зверь такой?
Версию 5.6.30 — знаю, 7.1.1 — знаю, а вот 5.6.4 — не знаю
http://php.net/downloads.php
Можете определить, например, в своем ServiceProvider
app("url")->setDefaultNamedParameters(["locale", app()->getLocale(), "userId" => app("auth")->user()->getKey()]);
а потом использовать в роутерах
app('router')->pattern('locale', '(' . implode('|', config('app.locales')). ')');
app('router')->group(['domain' => '{locale}.telenok.com'], function ()
{
app("router")->post("some-url", array("as" => "some-name", "uses" => "SomeClass@somemethod"));
});
https://github.com/laravel/framework/blob/master/src/Illuminate/Routing/RouteUrlGenerator.php#L208
The share method has been removed from the container. This was a legacy method that has not been documented in several years. https://laravel.com/docs/5.4/upgrade#upgrade-5.4.0
Ох, если бы это было только единственное фатальное изменение… Были и другие: https://github.com/laravel/internals/issues/391
Краткий обзор нововведений в Laravel 5.4