С другой стороны кто-нибудь может удалить бандл, а тот же самый parameters.yml так и останется висеть набитый левыми переменными
Это к приложению относится, настройки бандлов в config_%env%.yml обитают.
Сносим бандл — все, симфони будет ругаться что лишние конфиги которые не к чему применить остались.
А за parameters.yml.dist следить да, надо самому
Подсказываю решение:
Это конечно круто, но как-то не то. А так в нужных местах можно было бы сделать так:
Начнётся всё с построения дерева конфигов. Примерно там же и будет похоронен юный падаван. «Зато никаких ошибок в конфигах» — говорили они =)
а мне в ларе этого иногда не хватает, особенно если кто-нибудь альтернативно одаренный без чтения документации будет писать в конфигах какую-то дичь (строки вместо чисел например). Или снесет пакет, а конфиги останутся. Или при клонировании репозитория — в ларе сам читай readme и ищи какие параметры в .env нужно прописать если никто не прописал в .env.example то что нужно. А симфони сгенерит при установке пакетов parametest.yml с дефолтными значениями где останется прописать свои параметры для окружения
есть простое объяснение почему все адекватные люди считают вашу статью унылой. можете прочитать по ссылке. Вкратце — установили фреймворк, а гонора будто скайнет написали
А этот текст ориентирован на полного новичка, которому нужно быстро слепить сайт на Yii2
И ему этот текст полезнее чем описанные вами навороты
и как вы предлагаете эти самые страницы редактировать?
В статье написано
Отныне они у вас вас будут подхватываться автоматически из папки basic/views/site/pages
круто, все равно придется верстать и складывать их в папку. Зачем тут фреймворк, если можно эти же сверстанные страницы положить в папку? Без «наворотов» это совсем бесполезно, даже вредно.
Одно дело когда юзер спрашивает о деталях реализации описанного в сабже — это норм
это норма, когда реализуемая вещь несколько сложнее того о чем можно прочитать в документации. Как выше уже сказали, статья ниже местного уровня. Вот если бы вы добавили админку для этих страниц, связали все это дело с varnish, да добавили обработку esi-блоков, например для форм, то было бы поинтереснее и полезнее.
Жду статью как сделать автозагрузку psr-4 через composer
Будет примерно так же полезно
А если серьезно — то микрофреймворки или генераторы для такой мелочи куда больше подходят, рекомендовать ради одного правила в url тащить довольно жирный фреймворк — плохой подход
про psr-2 — используйте http://cs.sensiolabs.org/
psr-3 это про логгирование, что-то у вас я там ничего такого не увидел
тут не завихрения, а просто будет не лапша и возможность отделить мух от котлет
это как раз «про тестовое задание» — потому что в таком виде мало кто посчитает что оно выполнено.
чтобы хоть как-то структурировать код. сейчас там лапша, для одноразового скрипта, который выполнили и забыли — пойдет, но статья говорит про самообучение, потому надо привыкать делать все по устоявшимся в сообществе правилам.
библиотека и внешний сервис — немного разные зависимости. Если библиотека окажется с багом — я могу отправить pull-request туда, а если не примут — использовать свой форк на крайний случай. А если тот же самый ulogin ляжет — что тогда делать?
тут смотря с какой стороны посмотреть и для чего это будет использоваться. мне спокойнее, если я как можно меньше завишу от внешних сервисов, да и никто не мешает сделать с socialite так:
public function redirectToProvider($driver)
{
if(empty(config('services.'.$driver))){//нет драйвера - нужно что-то сделать
abort(404);
}
return Socialite::driver($driver)->redirect();
}
Это к приложению относится, настройки бандлов в config_%env%.yml обитают.
Сносим бандл — все, симфони будет ругаться что лишние конфиги которые не к чему применить остались.
А за parameters.yml.dist следить да, надо самому
Это конечно круто, но как-то не то. А так в нужных местах можно было бы сделать так:
А в ларе придется самому за этим следить и исключениями бросаться
а мне в ларе этого иногда не хватает, особенно если кто-нибудь альтернативно одаренный без чтения документации будет писать в конфигах какую-то дичь (строки вместо чисел например). Или снесет пакет, а конфиги останутся. Или при клонировании репозитория — в ларе сам читай readme и ищи какие параметры в .env нужно прописать если никто не прописал в .env.example то что нужно. А симфони сгенерит при установке пакетов parametest.yml с дефолтными значениями где останется прописать свои параметры для окружения
и как вы предлагаете эти самые страницы редактировать?
В статье написано
круто, все равно придется верстать и складывать их в папку. Зачем тут фреймворк, если можно эти же сверстанные страницы положить в папку? Без «наворотов» это совсем бесполезно, даже вредно.
это норма, когда реализуемая вещь несколько сложнее того о чем можно прочитать в документации. Как выше уже сказали, статья ниже местного уровня. Вот если бы вы добавили админку для этих страниц, связали все это дело с varnish, да добавили обработку esi-блоков, например для форм, то было бы поинтереснее и полезнее.
с таким подходом лучше в личный бложек публиковать, а не на крупный ресурс
Будет примерно так же полезно
А если серьезно — то микрофреймворки или генераторы для такой мелочи куда больше подходят, рекомендовать ради одного правила в url тащить довольно жирный фреймворк — плохой подход
а для числодробилок лучше что-нибудь другое использовать
ээээ… и это все чтоль?
psr-3 это про логгирование, что-то у вас я там ничего такого не увидел
тут не завихрения, а просто будет не лапша и возможность отделить мух от котлет
это как раз «про тестовое задание» — потому что в таком виде мало кто посчитает что оно выполнено.
чтобы хоть как-то структурировать код. сейчас там лапша, для одноразового скрипта, который выполнили и забыли — пойдет, но статья говорит про самообучение, потому надо привыкать делать все по устоявшимся в сообществе правилам.
после — смотрите что такое psr-2 и psr-4
после — https://github.com/guzzle/guzzle
слишком много замечаний выйдет, нет смысла перечислять все
нужно больше социалок? не вопрос — https://socialiteproviders.github.io/
то последует попытка создать нового пользователя, т.к. Hash::make('any_string') будет все время различаться