ну такое... я допустим к последнему пункту пришел спустя 4 месяца фэйлов

ну мол... я херово делигировал задачи разработчикам оставляя самое сложное себе (потому что я в 2-3 раза быстрее сделаю а таймлайны жали)

в итоге у меня не хватало времени на контроль... разработчики не развивались....

вот с парным программированием выходит чутка лучше

за одним компом пилите?

ну да

не за моим

(

))

хорошая практика

я таким тоже промышлял когда был тим лидом

Ребята, а JMS Serializer/VirtualProperty только один может быть разве в Entity? O_o

тьфу, блин, кеш чистить надо оказывается просто бывает полезно )

Всех с наступающим

Всех с насту-пающим.)

https://github.com/symfony/symfony/issues/21103

ДА!

но судя по комментам как-то тяжко это заходит

гребанные старперы.

надеюсь протолкнут

да блять в джаве уже лет 6 как ушли от описаний бинов в xml

крутота

не надо писать свои кастыли

еще б сделали чтобы автогенерация имени была

ну типа написал @Service и все

ну в jms di extra это есть

то что там это есть это понятно. я и сам такое могу написать на коленке

а надо ж чтоб сама симфони такое поддерживала

читаю описание и не понимаю примеры

они какие-то странные

особенно с геттерами

В JMS DI какие-то неявные баги с @Service

например когда сервис надо сделать из контроллера

у меня для этого ActionBundle теперь

А шо за ActionBundle?

ну тип позволяет регистрировать отдельные экшены как сервисы

я избавился от http-specific вещей в контроллерах так что теперь у меня их попросту нет, есть просто сервисы уровня приложения

и отдельные "read-only экшены" которые генерят респонсы

по аналогии с ADR

мндя, мне еще учиться... )

я все хочу запилить на github простенький проект-пример.... @Enleur даже накинул идей

но времени у меня пока не появилось(

блин, такое чувство что в elasticsearch 1.7 нет возможность сделать range по месяцу-дню... т.е. нечто типа: "range": { "date_birth_searchable": { "from": "01-01", "to": "01-31", "format": "M-d" } }

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

в маппинге эластика: date_birth_searchable: {type: date, format: "MM-dd"} с использованием FOSElasticaBundle.

https://github.com/symfony/symfony/issues/21103

Мусорный рфц ес честно

Мусорный рфц ес честно

то есть ты против аннотаций для регистрации сервисов?

Скорее да

аргументируй?

p.s. мое мнение что аннотации - половинчатое решение

1) сами по себе аннотации - так себе. 2) один класс может иметь больше одного дефинишна в контейнере. 3) для нубов выгода есть, да, меньше конфигов, но потом от этого лишь боль 4) Описание маппинга инжекта на проперти размывает конфиг. Не сразу понятно что вообще происходит.

1. спорно 2. несколько аннотаций на один класс тоже можно навесить. 3. с теми конфигами что сейчас так и так боль 4. инджект на проперти плохая идея изначально

А в чем боль с конфигами?

в том, что нужно править больше, чем в одном месте

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

- проблемы когда в разных частях системы требуются разные сервисы

а мусора не будет, точно так же как и с роутами. Роуты пишешь в одном месте, нужно список - проследуйте в debug:route

ну мол... у тебя есть дефинишены entity manager-а

и надо распихать нужные по нужным сервисами

половина сервисов хотят app.entity_manager.read а вторая app.entity_manager

там же есть вариант с присвоением сервисов по имени, а не по классу

хотя ладно... мою проблему можно решить введя дополнительный адаптер

я просто ленивая жопа(

- проблемы когда в разных частях системы требуются разные сервисы

Я все ещё не вижу проблемы. Чем аннотации это разрулят?

Я все ещё не вижу проблемы. Чем аннотации это разрулят?

аннотации не разрулят)

мне просто не нравится yaml

ERROR: S client not available

а мусора не будет, точно так же как и с роутами. Роуты пишешь в одном месте, нужно список - проследуйте в debug:route

Зависимости сервисов он не показывает, если я правильно помню

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

Зависимости сервисов он не показывает, если я правильно помню

не показывает.

в ContainerDumper вроде как есть дополнительный драйвер для сброса всей иерархии зависимостей в виде графа который можно посмотреть потом

GraphvizDumper

Ну это уже дебаг. А вот для generic конфига сервисов я пока не вижу альтернативы xml/yaml файлу

Все таки похоже когда конфиг становится болью имеет смысл запилить своё частное решение

Ну или ещё один бандл

ну фича ведь ещё не зарелизена

Да ее не пустят, отвечаю)

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

ну и по каментам и так всё понятно

половина сервисов хотят app.entity_manager.read а вторая app.entity_manager

вариант с квалифаерами это б решил все

вариант с квалифаерами это б решил все

ну тип того)

https://github.com/symfony/symfony-standard/commit/9b2e12f6d5543f7d441e7d91ae57e16644aada53 можно убирать класс кеш и бутстрап

а что поменялось координально что теперь можно?

там какие-то движухи помню были с пхп и композером. композер вроде щас сам это делает

https://github.com/symfony/symfony/issues/20668

вот

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

из-за огромного количества файлов

да, это в доке есть

недавно появилось кстати

раньше не было

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

ну то есть.... исходники никогда не будут меняться

может имеет смысл отключить инвалидацию кэша для opcache?

?

пойду напишу маленькай тестик и посмотрю как влияют оптимизации

пока у меня минимальное время обработки запросов 20ms

ну если поупарываться с гидраторами для доктрины и на read-only запросах удавалось выжать 15ms

причем 11ms это примерное время бутстраппинга симфони