cohision/coupling

Давай. :)

Спасибо за беседу. :)

вы поговорите, а я домой пойду))

только сначала терминологию синхронизируйте))

а то cohision и coupling часто путают))

а то cohision и coupling часто путают))

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

У меня возник вопрос.

Я подчичаю депрекейты для симфы 4.

И вот logout_on_user_change поставил в true

И теперь не логинится.

Что бы это могло быть?

fos?

Нет. Просто обычный

Это нормально что после перехода на 4 симфони http exception'ы не обрабатываются? Или я что-то не так сделал? http://beta.api.findmedia.xyz

И еще если грузить зависимости компосера без дева то удаляется дотенв и все падает. Это все такое сырое или я тупой просто?

Если смотреть на этот гайд https://symfony.com/doc/current/deployment.html то symfony_requirements вообще не существует, а —no-dev ложит дотенв

https://github.com/symfony/symfony/blob/4.0/composer.json не тянет dotenv ни в каком виде.. значит его тянет какой-то пакет как dev зависимость

в чём проблема самому добавить то?

В том, что он добавлен в дев из коробки, и врятли это сделали "по приколу"

пересмотри composer.json - там нет dotenv. его тянет другой пакет а не symfony/symfony

Он есть, ctrl+f

По той ссылке, что ты скинул

replace

symfony/dotenv

секция

а не require-dev

Блин, мой компосер жсон вообще не похож на этот

Хотя я не так давно создавал проект с нуля

Ну он и не должен быть похож...

зависит от того как ты создавал

В общем в скелетоне dotenv в require-dev

https://github.com/symfony/skeleton/blob/4.0/composer.json

такой у тебя?

Да

composer create-project symfony/skeleton my-project

ну так впили dotenv в require вместо require-dev

Ну дк это же не нормально что он сейчас в дев зависимостях

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

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

Symfony Dotenv should only be used in development/testing/staging environments. For production environments, use "real" environment variables.

https://symfony.com/doc/current/components/dotenv.html

это то, про что говорил Фабиан

Очень странное решение

А чего странного?

В чем тогда смысл юзать .env, если это должно использоваться только на дев?

В чем профит

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

Конфиг так же было удобно редактировать

В чем тогда смысл юзать .env, если это должно использоваться только на дев?

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

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

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

Чем тогда это отличается от конфига yml, который был раньше? Только возможностью допустим в докере прописать environment?

Чем тогда это отличается от конфига yml, который был раньше? Только возможностью допустим в докере прописать environment?

тем что не нужно редактировать файлы

у тебя просто есть .env и для продакшена будут засечены энв переменные. Если у тебя вдруг не отличаются параметры какие-то с dev - тебе никто не запрещает их из .env подгружать

которая сейчас мягко скажем кривая и страшная... вот жду пока @Big_Shark проснется - хоть обсудить с кем

Я тут только 2 часа назад домой добрался, 8 часов за рулём был, ещё не добрался

@fes0r Вроде все круто, но единственное я не очень понимаю как в public function resovlePost(Post $post) приходит $post?

@fes0r Вроде все круто, но единственное я не очень понимаю как в public function resovlePost(Post $post) приходит $post?

короч я сейчас пытаюсь сделать следующую схему. - ресолвер latestPosts по схеме возвращает список Post. То есть ресолвер должен вернуть "список чего-то что мы назовем Post". - мы определили дефолтный ресолвер для типа Post, и он будет вызван для каждого элемента списка. Соответственно Post придет из парент ресолвера. То что там тип Post у аргумента - это так совпало. ты мог бы просто массив прокинуть например (хотя с массивом не прокатит автовайринг, придется забирать из контекста)

или слишком жестко?

или слишком жестко?

Нее, слишком жестко, и слишком захардкожено на мой взгляд

Не гибко будет в итоге, думаю надо чтото более простой

Нее, слишком жестко, и слишком захардкожено на мой взгляд

что значит "захардкожено"?

ну давай по другому

что бы более предметно - возьмем инстаграм

у тебя там есть посты

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

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

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

может, тогда будет так: public function resolvePost(int $id): Post;

и дальше ресолвер по типу подхватит

ERROR: S client not available

иначе как ты предлагаешь? как сделать проще?

Так у тебя че 2 резолва с одним именем тогда бедет?

ммм.... не можешь назвать transformPost))

тот который по типу

я предлагаю 2 метода, онит как у тебя конвертирует, а второй загружает

то есть вместо мудрения с ресолверами сделать возможность делать для типов трансформеры?

да

трансформер ~= дефолтный ресолвер для типа

/** * @Resolver(path="latestPosts", transformer="Post") */

вот так допустим

ммм.... нет

это как-то глупо

хотя...

не, глупо

у тебя на уровне схемы есть что должен "трансформировать" latestPosts. Нет смысла это прописывать на стороне ресолвера...

ну да, ну тогда у теб просто должно быть

хм... дай подумать...

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

/** * @Resolver(path="posts") */ public function resolvePost(int $id) { return $this->gateway->getPostById($id); } /** * @Transformer(type="Post") */ public function transformerPost(Post $post) { return [ 'id' => $post->getId(), 'title' => $post->getTitle(), 'brief' => $post->getBriefDescription(), 'body' => $post->getBody(), ]; }

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

ну и еще - Transformer(type="Post") - как думаешь не будет недоразумений что этот тип - это тип по схеме а не то что в аргументах

я потому это ресолвером и назвал... что сомневался

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

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

ну и еще - Transformer(type="Post") - как думаешь не будет недоразумений что этот тип - это тип по схеме а не то что в аргументах

Думаю нет, вроде норм

Но как тогда быть с resolvePostPreviewImage вопрос

там ка бы резолвер

но нам же нужен и трансформер

трансформер не обязателен

Либо указания что он не нужен

в качестве оного выступает дефолтный ресолвер

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

(потому я все еще сомневаюсь что надо вводить Transformer ибо это все же ресолвер))