но мне кажется это будет логичней

на каждый тип отдельный резолвер

по инстаграмму основной вопрос у меня - у тебя есть десяток разных списков с пагинацией

и кто будет формировать этот список?

ну то есть.... превращать "что-то" что мы достали из базы в json

паджинатор?

окей без пагинации

у тебя есть ресолвер

function resolveMostPopularPosts() { return $this->db->fetchMostPopularPosts(); }

возвращает он нам.... ну допустим сущности доктриновские

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

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

я не понимаю как

где будет этот код: return [ 'id' => $post->getId(), 'title' => $post->getTitle(), 'brief' => $post->getBriefDescription(), 'body' => $post->getBody(), ];

Там же где и сейчас, зачем его трогать то?

когда и как будет вызываться ресолвер для превьюшки?

Там же где и сейчас, зачем его трогать то?

а где сейчас?

{ latestPosts(n: 10) { id title thumb(400, 400) } }

вот пример запроса

списков таких - десяток

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

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

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

что есть пост ресолвер?

а блин...

"пост"

но это же так как у меня в примере, нет?

/** * @Resolver(type="Post") */ public function resovlePost(Post $post)

То что я предлагаю переделать в трансформер

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

меня смущает факт того что у меня дефолтный ресолвер который один на всю схему будет дефолтным трансформером) я не хочу новые термины вводить... точнее меня это смущает

меня смущает факт того что у меня дефолтный ресолвер который один на всю схему будет дефолтным трансформером) я не хочу новые термины вводить... точнее меня это смущает

А как у тебя будет выглядить этот самый дефолтный ресолвер?

А как у тебя будет выглядить этот самый дефолтный ресолвер?

посмотри как он выглядит в webonyx

И в твоем варианте я не понимаю как мы сделает доставания поста по ид)

посмотри как он выглядит в webonyx

Как гавно же, не?

И в твоем варианте я не понимаю как мы сделает доставания поста по ид)

ну просто еще один ресолвер же

у тебя ж по id будет филд

что-то типа post(id: Int!)

а да - я не говорил что расчет только на описание схемы через SDL?

во всяком случае пока

ты по сути можешь сделать даже так: /** * @Resolver(type="Post") * @Resolver(field="post") */ public function resolvePost(Post $post);

типа Post тебе достанет аргумент ресолвер симфоневый

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

например если тебе права надо проверить

а да - я не говорил что расчет только на описание схемы через SDL?

это норм

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

окей, ушел пилить прототип дальше

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

просто с ресолверами типов и если в graphql появятся дженерики... ух

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

Ок

это будет просто круто)

Н.а.У.ч.И.с.Ь задавать вопросы

какой пост где что

Ладно, попробую сам разобраться

Такой трабл.Использую KNPpaginator и когда добавляю посты на сайт обычным for in как указано в доке на гитхабе, то самый новый пост оказывается в конце первой страницы.Может у кого-то была подобная проблема?Вроде сделал всё как указано в доке

Решил таким образом $dql = "SELECT a FROM AppBundle:Post a ORDER BY a.id DESC";

А было так $dql = "SELECT posts FROM AppBundle:Post posts";

Ну это просто сортировка

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

вешать событие на post_bind и в цикле все поля перебирать?

не

просто constraint

callback constraint

ERROR: S client not available

в форме можно прямо делать

добавляешь в configureOptions

'constraints' => Callback(func() {})

что -то такое

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

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

а сама реализация уже на твое усмотрение, кроме перебора в цикле других способов не вижу)

Как в контроллере у объекта FormInterface переопределить значение атрибута одного из полей? Я нашел только способ, когда полностью переопределяется поле $form->add('search', null, [ 'data' => $searchString ]);Но оно вылетает с ошибкой You cannot add children to a submitted form, да и визуально это хреново выглядит

ты пытаешься редачить форму после того как ее засабмитили

делай это перед сабмитом

а вообще сделай это внутри формы

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

Спасибо! Да, изначально хотел в форме делать, но не догадался посмотреть параметры createForm()

В правилах написания рецептов флекса есть такое The package does not depend on symfony/symfony or symfony/security Что делать если мне надо symfony/security для библиотеки?

по-умолчанию ведь security не идет в базовой установке

Пропиши в композере

Она поставится

Если им не нужна секурити, это не говорит о том, что она не может быть нужна тебе

я понимаю как оно делается. а его примут?

Посмотри на гитлабе есть ли принятые с зависимостью от секурити

сек

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

И как они советуют выходить из ситуации

не найдено

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

Чтоб твоя либа работала и без секурити

можно сделать ход конем. вдруг примут )

там и ответ найдется

вижу в сонате есть зависимость