в роутинге я не вижу указание папки контролера t_list_params: path: /list-params defaults: { _controller: TBundle:Params:index } TBundle - бандл Params - контролер

ну потому что ты бандл указал и используешь стандартный конвеншен

я просто аннотации юзаю)

я просто аннотации юзаю)

для роутингов?

В ParamConverter. https://symfony.com/doc/current/bundles/SensioFrameworkExtraBundle/annotations/converters.html

спасибо

подскажите пожалуйста а @ParamConverter * описывать в yml можно?

подскажите пожалуйста а @ParamConverter * описывать в yml можно?

нет

напиши ArgumentResolver

и тогда нигде ничего не надо писать

Братья, я возможно уже спрашивал про JMS Queue Bundle, а мб и нет, по поиску не удалось найти свои вопросы, сорян если повторяюсь

Вообщем не было ли у кого нибудь нареканий с ним?

я когда-то пользовался (ооочень давно) нареканий не было а какой вопрос?

Ну просто у них используется JMS DI Extra, сервисы они через него не определяют конечно, но @DI\InjectParams делают охотно, а тут не так давно был момент, когда весь этот DIExtra не смог генерировать PHP классы и делать EVAL из-за сонаты)0 И вообще он там очень много mkdir делает и всяких ужасов, меняет приватные свойства, папки ресурсов конейнера: $ref = new \ReflectionProperty('Symfony\Component\DependencyInjection\ContainerBuilder', 'resources'); $ref->setAccessible(true); $ref->setValue($container, $resources);

PHP код генерит

Лезет в места, которые могут спокойно меняться и дофига чего нарушать может, там один Finder\PatternFinder чего стоит

Ну просто у них используется JMS DI Extra, сервисы они через него не определяют конечно, но @DI\InjectParams делают охотно, а тут не так давно был момент, когда весь этот DIExtra не смог генерировать PHP классы и делать EVAL из-за сонаты)0 И вообще он там очень много mkdir делает и всяких ужасов, меняет приватные свойства, папки ресурсов конейнера: $ref = new \ReflectionProperty('Symfony\Component\DependencyInjection\ContainerBuilder', 'resources'); $ref->setAccessible(true); $ref->setValue($container, $resources);

di extra не нужен, просто выкинь его

Я говорю, что это обязательная зависимость для Queue Bundle

Он нужен ему

обязательная зависимость !== активировать в аппкернеле

он нужен только для админки

а там админка встроенная убогая

Вон оно как

Спасибо

Вон оно как

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

а так я юзаю - отличная штука для проектов, где кролик - оверхед, жаль что не поддерживается

В репе еще какой то retry_scheduler

Но делается че то типа: if ($this->retryScheduler === null) { $this->retryScheduler = new ExponentialRetryScheduler(5); }

Народ, есть ли аналог jsfiddle, где можно легко указывать подключаемые к коду пакеты composer?

Аналог для PHP, само собой.

Аналог для PHP, само собой.

http://phpfiddle.org/

?

Там composer-пакеты можно разве подключать?

Там composer-пакеты можно разве подключать?

Не знаю, но написано вот это Provide a dedicated MySQL database and best chosen PHP libraries from open resources

Ну он мало чего предоставляет. Мне вот, например, надо пример с Guzzle накидать.

Но делается че то типа: if ($this->retryScheduler === null) { $this->retryScheduler = new ExponentialRetryScheduler(5); }

повторюсь - ты его легко можешь зарегистрировать в DI ручками и не нужно будет подключать кучу гуано

если необходимость есть

лучше 3-4 сервиса быстренько прописать чем весь DiExtra заиметь

уже меньше чем 2 недели осталось до 3.3 релиза

готовы апдейтится?)

Неа.. там же все по-новому?)

там di хороший

ну не то чтобы все, есть много фичей с DI

которые с радостью затащу на проект

Кто то говорил, что там необходимо будет сервисы по FQCN именовать

А много сложностей будет с обновлением с 2.8?

опционально

Мы просто собираемся на 3.2 пересаживаться.

ну с 2.8 главное до 3.0 обновиться

Я подумал, может сразу на 3.3?

Ну да.

Это так

Депрекейты все удалить

а 3.0 и выше уже без проблем

Кто то говорил, что там необходимо будет сервисы по FQCN именовать

их давно так можно было именовать, я на 3.2 версии так делаю с новыми сервисами

То есть если проект на 3ке - то ничего страшного?

Да то что можно было - это понятно

не. ничего не сломается

А вот насколько удобно..

оч удобно

Вот в yml файликах писать namespaces

Ладно еще делать ->get(ServiceClass::class)

Это да

А вот в конфиге.. Копировать namespace

жмешь правой кнопкой на класс

Copy Reference

и вставляешь в свой yml

:с

А что значит FQCN?

ERROR: S client not available

fully qualified class name

фулл кваливид клас нейм

это я прочитал ) что оно значит-то?)

А вот в конфиге.. Копировать namespace

А разве Symfony Plugin не работает?

А разве Symfony Plugin не работает?

При вводе имени сервиса он же ничего не дополняет

Только когда class: начинаем заполнять

Ну так будет, как релиз сделают

Обновят

О

Они вроде как быстро это делают

мне еще нравится psr based discovery фича

А если кто то не хочет использовать FQCN.. Обалдеть глаза резать будет

всякие репозитории автоматически регать

всякие репозитории автоматически регать

Даа!

То есть DI теперь будет выглядеть громоздко?

Ведь в секции arguments будут FQCN

наоборот не

Ну алиас можно сделать коротким

А классы-то нет

services: App\Foo\Bar: ~ куда проще чем services: app.foo.bar: class: App\Foo\Bar arguments: ...

меня всегда бесило самому писать алиасы

services: App\Foo\Bar: arguments: - \Bar\Baz - \Baz\Quux

Блин, как я не люблю масштабные изменения в привычной работе...

services: App\Foo\Bar: arguments: - \Bar\Baz - \Baz\Quux

аргументы можно не указывать, автовайринг же)

Ну так не всегда ж хорошо

А если у меня интерфейс?

ну еще можно в одну строку написать App\Foo\Bar: ["@Bar\Baz", "@Baz\Quux"]

а в чем проблема с интерфейсом?

Ну это пример с короткими неймспейсами :)

А могут же быть и намного длиннее

ну хз Bar\Baz vs bar.baz

Ну у меня несколько классов расширяющих интерфейс