Java клиент все еще в разработке

по сути кроме apollostack этим никто не занимается

глянул топ реализаций под симфони....

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

то есть кода

--

относительно GraphQL было бы круто для PHP реализовать что-то типа... абстракции... что бы можно было например дергать данные напрямую из базы

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

никаких ORM

никакого булшита

относительно GraphQL было бы круто для PHP реализовать что-то типа... абстракции... что бы можно было например дергать данные напрямую из базы

Ну надо как-то ограничения хорошо описать

Чтобы не досить самих себя)

ну это да... есть такое

еще у меня открыт вопрос по поводу инструментов вроде документации и mock сервера

ну короч... graphql как минимум стоит того что бы поинвестигать

как раз через пару месяцев подтянутся клиенты

https://github.com/symfony/symfony/pull/21071 смержили тоже кстати

интересно как оно будет работать вместе с https://github.com/symfony/symfony/pull/21133

? services: _defaults: public: false autowire: ['_construct', 'set*'] AppBundle\Service\ServiceA: {} AppBundle\Service\ServiceB: {} AppBundle\Service\ServiceC: {}

а учитывая что движуха пошла в сторону именования сервисов по типу референсов, то я думаю что-то решат с адаптированием @Service/@Component/@Named

https://gist.github.com/fabpot/ddcee0f49dfd97be29dbbd973b93cfe8

круто же не?

эт ахуенно)

я короче пошел толкать тему https://github.com/symfony/symfony/issues/21103

я короче пошел толкать тему https://github.com/symfony/symfony/issues/21103

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

хз правда на сколько это "медленно", у нас на проекте 1200+ сервисов

над проверить на досуге

Там ещё аргумент в том, что с аннотациями сервисы станут тоже завязаны на фреймворк.

это пока PSR нет

у роутов есть аннотации, орм - тоже, валидация туда же

Ну так PSR и запил этой фичи в symfony - разные вещи немного.

Да. И там уже писали, что контроллер и так завязан на контейнер.

в Spring пока не приняли JSR с @Inject и @Named, были свои "завязанные на фреймворк" @Autowired и @Component

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

все довольны

Не, ну с PSR-то норм, в принципе будет.

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

Zend DI, Symfony DI, Php-DI, Laravel и че там еще - они совсем разные

Надо ещё Yii вспомнить)

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

ну вообще 3.3 версию теперь жду больше чем 3ю

столько плюшек добавили за раз

Не люблю Yii

и вообще общая нацеленность на DX

А что там в 3.3 будет? Я как-то не очень следил за новостями.

https://gist.github.com/fabpot/ddcee0f49dfd97be29dbbd973b93cfe8 вот это валидный конфиг для сервисов

Это я видел.

А как там разруливается возможность создать два сервиса из одного класса? Или можно и с произвольными айдишниками как сейчас?

можно прописывать дефолты, к примеру что autowire: true и теперь не обязательно писать class если имя сервиса совпадает с референсом класса

А как там разруливается возможность создать два сервиса из одного класса? Или можно и с произвольными айдишниками как сейчас?

произвольные айдишки, да

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

можно прописывать дефолты, к примеру что autowire: true и теперь не обязательно писать class если имя сервиса совпадает с референсом класса

Про автовайр я помню. А вот про эту сокращённую нотацию пока подробностей не читал.

То есть, имя сервиса теперь будет либо FQCN, либо айдишник сервиса, так?

да

в контроллерах можно сделать $this->get(MyService::class)

хоть и не советуют, но все же)

И если сервис единичный, можно юзать FQCN, опускать параметр class и т.п.

да все верно

Ну, миленько. Для простых приложений будет лаконичненько и красиво.

вот мне очень нравится

? services: _defaults: public: false autowire: ['_construct', 'set*'] AppBundle\Service\ServiceA: {} AppBundle\Service\ServiceB: {} AppBundle\Service\ServiceC: {}

Ага, норм.

@fes0r помнит я долго по этому поводу ныл еще когда autowire не появился))

проблема с аннотацией для сервисов в сложном кеше?

ERROR: S client not available

если я правильно понял

в целом да

и в упертости главных мейнтейнеров

а зачем кстати {}

Iltar и wouterj уперлись рогами

яснопонятно

а зачем кстати {}

да пардон, уже можно ~ писать

AppBundle\Service\ServiceA: ~

угу

если они еще дальше пойдут с контейнером, то ларовский контейнер не будет таким крутым на фоне симфони))

если они еще дальше пойдут с контейнером, то ларовский контейнер не будет таким крутым на фоне симфони))

там недавно выкладывали бенчмарки - симфоневый контейнер один из самых быстрых.... в большинстве тестов он вообще самый быстрый

если к этому еще уровень удобства такой добавится вообще ништяк)

Если мне не изменяет память, он раньше был чуть ли не самым медленным. Они его круто оптимизировали или мне память изменила?

там же кеши, компиляция и вся херня

а в ларе все в рантайме каждый раз собирается

на сколько я помню

Если мне не изменяет память, он раньше был чуть ли не самым медленным. Они его круто оптимизировали или мне память изменила?

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

контейнер собирается на деплое

поэтому все норм

единственное что singleton сервисы достаются медленнее чем prototype что меня несколько удивляет

прототипы инлайнят же

а еще непубличные сервисы в целом шустрее могут быть, из-за того же инлайнинга

точняк

Возможно глупый вопрос, но как кто реализовывает в селекте пункт "любой". Допустим у меня есть список городов, который я вывожу в селекте, этот список связан с постом как многи ко многим (т.к. по городу может быть много постов и поста может быть много городов). но есть посты, которые относятся ко всем городам. И каждой решение которое я придумываю - мне кажется неправильным. Последнее к чему пришел - это сделать отдельное свойство у поста - все города.

для всех городов выбирай посты, где в этом поле null

Но тогда как отделить те посты, которые без города?)

ну тогда без вариантов должен быть город "Все города"

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

Yuriy Добавить в дата в форму

Null Object.

3-м параметром для createForm?, добавлял, да скрытые поля выводятся но эти значение до БД не доходят они теряются вот сдесь $em->persist($estimated); $em->flush($estimated); хотя в объекте формы на этапе валидации они присутстовали