Кто знаком yiisoft/yii2-httpclient? Делали попытки повторного подключения при ошибках в ответе?

Один раз пробовал, выбросил, возми газл.

desktop: windows, server:debian centos. винды за глаза хватит. в том случае если вам не нужно писать для проекта какие то демоны, что то конвертировать, и т.п...

С centos поработал на серверах, но хочу с ubuntu куда-то переползти, ибо последнее время начала чот крашится с переодичностью ну и + я не на LTS.

Он там мне палки в колёса вставил, вроде не мог на дурную апишку заголовок верно передать...

Один раз пробовал, выбросил, возми газл.

газл тоже есть ) но уже сделано

газл тоже есть ) но уже сделано

Тоже не зашел тебе?

С centos поработал на серверах, но хочу с ubuntu куда-то переползти, ибо последнее время начала чот крашится с переодичностью ну и + я не на LTS.

всегда для серверов поднимаю Debian+php-fpm+nginx проблем не знаю...

А подскажите как сделать пути чтобы вышло такое domainname.ru/car_name.php

http://www.yiiframework.com/doc-2.0/yii-web-urlmanager.html#$suffix-detail

Народ, подскажите пожалуйста, можно ли в миграции получить объект класса из DI не как на скрине в 12 - й строке, а более изящно? Типа того, как в контроллере переопределяем конструктор, добавляя в его параметры переменную нужного класса, и DI нам сам ее создает, остается лишь в свойство класса ее пропихнуть. Или в миграции так не получится?

собвственно к чему такие сложности в миграции?

какая цель? В чём полезность такого подхода?

там 4 строчки, вы туда DI зачем-то приделываете.

цель больше узнать, можно ли в миграции получить объект сервиса более изящно, чем на примере

узнавать надо не на миграциях.

коллегам жизнь усложняете.

DI там нужен, т.к. у сервиса в конструкторе куча параметров, чтоб через new их не создавать пачкой, вот зачем DI

Yii::$app->discount… нет?

не...как компонент точно этот сервис мне не нужен

а как не в миграциях он создается?

можно скрин?

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

щас

можно скрин?

чот какаято жесть )

конкретно этот сервис не используется пока кроме как в миграции, но все может быть. Накидал пример по - быстрому в SiteController

зачем в конструктор контроллера это все передавать?

или делай компоннет yii или вообще не связанный с yii класс в /components (я так обычно делаю)

чот какаято жесть )

в чем жесть? бизнес логика инкапсулирована в сервисе. Что ж тут плохого? Я сервис дергаю хоть с миграции, хоть с контроллера вебовского, завтра с апи его дерну. Объект сервиса получаю из DI, т.к. таким же образом в конструкторе у него репозиторий карт прилетает, и менеджер транзакций

или делай компоннет yii или вообще не связанный с yii класс в /components (я так обычно делаю)

Компонент во - первых - часть фреймворка, а не бизнес логики, в отличие от сервиса, который является частью доменного слоя

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

ощущение что следуешь паттерну ради паттерна не понимая выгод )

он не сломал конструктор.

Я ничего не ломаю) конструктор в Yii создается через DI, который парсит параметры, и создает переменные нужного типа

будет работать.

Где сервис не нужен - там я его пихать в конструктор не собираюсь естественно.

только туда, где нужен

вам просто нужно было посмотреть какими путями можно было сделать внедрение зависимости.

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

знаете, что самое забавное будет?

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

http://joxi.ru/n2YabaHjy91126 - стандартный конструктор

а он туда прикрутил свой сервис

будет работать. Проверено.

вы сами попробуйте.

В gridview неочевидное поведение когда юзаешь Fortatter. 'format'=>['datetime','php:d.m.Y H:i:s'] Игнорирует timezone который глобально задан в конфиге.(а еще и в системе) Так и должно быть ?

а он туда прикрутил свой сервис

а в твоем скрине еще один конструктур куда прилепили модуль и id ;)

Да, Алексей, это работает. Мы переопределяем конструктор конкретного контроллеро всего - навсего

да работать то будет, только зачем так делать? теперь мне надо помнить что гдето поменян конструктор и нельзя привести все конроллеры к общему знаменательлю если что. А когда контроллеров перевалит за 100 и каждый будет лепить свой - будет ад

просто потому что DI это модно

это удобно.

а не модно.

это удобно.

да

вместо того чтобы сделать компонент и убрать проблему в приниципе

ну ооок )

вы просто не доросли. У вас ещё всё впереди ;)

да

ну вообще конечно если у тебя класс != один контроллер, то лучше в метод наверное инжектить

:)

началось.

все понял, устранился )))

ну вообще конечно если у тебя класс != один контроллер, то лучше в метод наверное инжектить

да даже если и один метод в контроллере. Пока ты все new Object() сделаешь - толщина контроллера перевалит за высоту экрана

да даже если и один метод в контроллере. Пока ты все new Object() сделаешь - толщина контроллера перевалит за высоту экрана

не понял, yii не умеет инжектить в метод из контейнера?

умеет.

а ну если инжектить из контейнера - то пол беды) но все же, строкой больше в контроллере)

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

а ну если инжектить из контейнера - то пол беды) но все же, строкой больше в контроллере)

какой?

а когда начинаешь делать DI как тут - возникает 100 точек кто что-то может пойти не так

зато DI )

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

если ты начал думать об архитектуре когда у тебя 100 контроллеров, то ты уже попал :)

:-)

нет, я думал ДО

и никаких проблем

молодец, думай дальше.

поэтому я против когда меняются стандартные методы

но не надо нам доказывать что мы что-то делаем не так.

да пожалуйста.

ок ок

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

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

поэтому я против когда меняются стандартные методы

инжектить зависимость это не страндартный подход?

только мы не знаем, что там у вас, а вы что у нас.