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

хотя, мб дырявый роутер где-то внутри сетки...

ну это тоже такое

Плюс часто ещё даже не ваш лоад балансер уже перехватывает https и дальше вам уже http идёт

Всякие ингрес контроллеры как работают в gke например

ну типа это же избыточная бессмысленная нагрузка на CPU с защитой от мнимого внедрения m-in-m в датацентре

Уфффф, скажу не супер популярную вещь, но может человек работает в гос компании

Блин, родились видения сериала аля "Разделение" + "Силиконовая Долина"- но про огромную корпорацию в которой работают конкурирующие команды и пытаются при помощи "грязной игры" заработать себе место под солнцем. Вот одна из арок будет про mitm

Олег, тебя заблокировали (spam) Сообщение предлагает сомнительную возможность заработка с высокой доходностью и призывает писать в личные сообщения, что типично для спама и мошенничества.

Добрый день, можете подсказать что я не так делаю? падает на фабрике 2) App\Tests\Form\OrderFormTypeTest::testSubmitInvalidData ArgumentCountError: Too few arguments to function App\Form\OrderFormType::__construct(), 0 passed in /media/roman/383be9ee-c114-4bf8-8956-66b985661cb4/home/awesome_projects/store/vendor/symfony/form/FormRegistry.php on line 78 and at least 1 expected

<?php declare(strict_types=1); namespace App\Tests\Form; use App\Form\OrderFormType; use PHPUnit\Framework\MockObject\Exception; use Symfony\Component\DependencyInjection\ParameterBag\ContainerBagInterface; use Symfony\Component\Form\Test\TypeTestCase; class OrderFormTypeTest extends TypeTestCase { private array $services; / * @throws Exception */ protected function setUp(): void { parent::setUp(); // Создание мок-объекта для ContainerBagInterface $this->containerBagMock = $this->createMock(ContainerBagInterface::class); $this->containerBagMock->method('get')->willReturn(dirname(__DIR__, 2) . '/config/dictionaries.php'); } public function testSubmitValidData() { $formData = [ 'service' => 500, // Выбор услуги 'email' => 'test@example.com', // Корректный email 'price' => 300, // Корректная цена ]; $form = $this->factory->create(OrderFormType::class, null, [ 'params' => $this->containerBagMock ]); // Подать данные в форму $form->submit($formData); <?php declare(strict_types=1); namespace App\Form; use Psr\Container\ContainerExceptionInterface; use Psr\Container\NotFoundExceptionInterface; use Symfony\Component\DependencyInjection\ParameterBag\ContainerBagInterface; use Symfony\Component\Form\AbstractType; use Symfony\Component\Form\Extension\Core\Type\EmailType; use Symfony\Component\Form\Extension\Core\Type\MoneyType; use Symfony\Component\Form\Extension\Core\Type\ChoiceType; use Symfony\Component\Form\Extension\Core\Type\SubmitType; use Symfony\Component\Form\FormBuilderInterface; use Symfony\Component\Form\FormError; use Symfony\Component\Form\FormEvent; use Symfony\Component\Form\FormEvents; class OrderFormType extends AbstractType { private array $services; / * @throws ContainerExceptionInterface * @throws NotFoundExceptionInterface */ public function __construct(private readonly ContainerBagInterface $params, ?string $services = null) { // Если $services не передан, используем значение по умолчанию if ($services === null) { $this->services = (require $this->params->get('dictionaries'))['services']; } else { $this->services = require_once $services; } } # This file is the entry point to configure your own services. # Files in the packages/ subdirectory configure your dependencies. # Put parameters here that don't need to change on each machine where the app is deployed # https://symfony.com/doc/current/best_practices.html#use-parameters-for-application-configuration parameters: dictionaries: '%kernel.project_dir%/config/dictionaries.php'

(не относящиеся к вопросу) какой-то OrderFormType слишком умный. Забирает в конструктом ВЕСЬ ParameterBag из контейнера

Щас покапался - формы вроде вооще не через конструктор конфигурируются, а через configureOptions Сама форма не через фабрику а через formBuilder - методом add указываешь название поля, FQCN типа и опции, описанные в configureOptions Но если нужно указать параметры в конструктор то это делается как описано тут https://symfony.com/doc/current/form/create_custom_field_type.html#passing-variables-to-the-form-type-template

да переделал в симфони вообще это так не работает #[Route('/order', name: 'order')] #[IsGranted('ROLE_USER')] public function order(Request $request, OrderService $orderService, ContainerBagInterface $params): Response { $form = $this->createForm(OrderFormType::class, null, [ 'services' => (require $params->get('dictionaries'))['services'], ]); } $form = $this->factory->create(OrderFormType::class, null, [ 'services' => (require dirname(__DIR__, 2) . '/config/dictionaries.php')['services'] ]); class OrderFormType extends AbstractType { public function buildForm(FormBuilderInterface $builder, array $options): void { $builder ->add('service', ChoiceType::class, [ 'choices' => $options['services'], 'placeholder' => 'Выберите услугу', ]) }); } public function configureOptions(OptionsResolver $resolver): void { $resolver->setDefaults([ 'services' => [], // Опция по умолчанию ]); } }

а можно и так // Создание формы с передачей необходимых параметров $form = $this->factory->create(OrderFormType::class, null, [ 'services' => (require dirname(__DIR__, 2) . '/config/dictionaries.php')['services'] ]); class OrderFormType extends AbstractType { public function __construct(private ?ContainerBagInterface $params = null) { } /** * @throws ContainerExceptionInterface * @throws NotFoundExceptionInterface */ public function configureOptions(OptionsResolver $resolver): void { $resolver->setDefaults([ 'services' => $this->params ? (require $this->params->get('dictionaries'))['services'] : [] ]); } } #[Route('/order', name: 'order')] #[IsGranted('ROLE_USER')] public function order(Request $request, OrderService $orderService): Response { $form = $this->createForm(OrderFormType::class); $form->handleRequest($request); } ```

да переделал в симфони вообще это так не работает #[Route('/order', name: 'order')] #[IsGranted('ROLE_USER')] public function order(Request $request, OrderService $orderService, ContainerBagInterface $params): Response { $form = $this->createForm(OrderFormType::class, null, [ 'services' => (require $params->get('dictionaries'))['services'], ]); } $form = $this->factory->create(OrderFormType::class, null, [ 'services' => (require dirname(__DIR__, 2) . '/config/dictionaries.php')['services'] ]); class OrderFormType extends AbstractType { public function buildForm(FormBuilderInterface $builder, array $options): void { $builder ->add('service', ChoiceType::class, [ 'choices' => $options['services'], 'placeholder' => 'Выберите услугу', ]) }); } public function configureOptions(OptionsResolver $resolver): void { $resolver->setDefaults([ 'services' => [], // Опция по умолчанию ]); } }

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

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

я не понял

buildView ?

я не понял

Вот так лучше тип сконфигурировать https://symfony.com/doc/current/form/create_custom_field_type.html#passing-variables-to-the-form-type-template А не внутри коструктора этого типа шарится в ContainerBag

так ContainerBag это то что предлагает симфони, с кешированием конфига. а require это чистый php

я искал аналог laravel config

так ContainerBag это то что предлагает симфони, с кешированием конфига. а require это чистый php

Ненене. Не стоит дёргать ContainerBag напрямую. Используйте, как рекомендуется и в статье и вообще в симфони сообществе - конфигурирования через service.yaml Код намного чище будет. Так же в версиях поновее можно аттрибутом указать что параметр конструктора стоит тянуть из параметра контейнера.

# This file is the entry point to configure your own services. # Files in the packages/ subdirectory configure your dependencies. # Put parameters here that don't need to change on each machine where the app is deployed # https://symfony.com/doc/current/best_practices.html#use-parameters-for-application-configuration parameters: dictionaries: '%kernel.project_dir%/config/dictionaries.php' services: # default configuration for services in *this* file _defaults: autowire: true # Automatically injects dependencies in your services. autoconfigure: true # Automatically registers your services as commands, event subscribers, etc. # makes classes in src/ available to be used as services # this creates a service per class whose id is the fully-qualified class name App\: resource: '../src/' exclude: - '../src/DependencyInjection/' - '../src/Entity/' - '../src/Kernel.php' # add more service definitions when explicit configuration is needed # please note that last definitions always *replace* previous ones как мне преобразовать dictionaries ?

я гружу массив из файла какой конфигурацией это сделать? <?php return [ 'services' => [] ];

Я щас уже не за компом

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

и передать параметр через DI?

App\Service\TravelLineService: arguments: $apiUrl: '%env(TL_API_URL)%' тип такого?

Открой ссылку там всё описано

Народ объясните пж, почему в доктрину не хотят завести поддержку morph связей, как это сделано в элокенте? Это же сильно удобнее чем раздувать сущность, либо в ручную следить за всеми формами и запросами, чтобы вложенная сущность правильно обрабатывалась. Я просто уже сижу пишу костыльный бандл для этого, вдруг у отсутствия этой фичи есть весомые корни

Народ объясните пж, почему в доктрину не хотят завести поддержку morph связей, как это сделано в элокенте? Это же сильно удобнее чем раздувать сущность, либо в ручную следить за всеми формами и запросами, чтобы вложенная сущность правильно обрабатывалась. Я просто уже сижу пишу костыльный бандл для этого, вдруг у отсутствия этой фичи есть весомые корни

Не знаю я делал такое даже в отдельной ветке как-то

Работало

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

Просто сделай доп сущность и все

ну то есть да, у этого есть оверхед на то чтобы родительская сущность сначала записалась, чтобы получить ее id, если она новая, а уже потом сохранять дочернюю. Но если делать дочернюю с полями entityType и entityId, то он в любом случае будет.

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

Что за морф связи

Мой кейс такой: есть сущность Attachment и сущности Comment, Message и Post в которых может быть Attachment

и тут либо раздувать бд и сущность Attachment, что не удобно в случае если появятся еще сущности которые захотят в себе иметь Attachment, либо в Attachment хранить entityType и entityId и ручками следить за этими "связями", что достаточно геморно

и тут либо раздувать бд и сущность Attachment, что не удобно в случае если появятся еще сущности которые захотят в себе иметь Attachment, либо в Attachment хранить entityType и entityId и ручками следить за этими "связями", что достаточно геморно

А что за слежение? В вашем случае мне кажется один раз установил два поля (type+id) и всё

А embedded не подходит?

Чот не понял, у коммента, сообщения и поста просто будут по своему аттачменту и всё

и тут либо раздувать бд и сущность Attachment, что не удобно в случае если появятся еще сущности которые захотят в себе иметь Attachment, либо в Attachment хранить entityType и entityId и ручками следить за этими "связями", что достаточно геморно

Полиморфные связи что ли?

Полиморфные связи что ли?

да

да

У доктрины есть такое, вроде

Ну у поста будет attachment_id и у кого-то ещё будет и что раздувать?

ну да или через rel таблицы

Чот не понял, у коммента, сообщения и поста просто будут по своему аттачменту и всё

типо CommentAttachment, MessageAttachment и тд?

нет - просто Attachment

Ты же можешь ссылаться на один аттачмент с несколькиз энтити

типо CommentAttachment, MessageAttachment и тд?

Там основная таблица с общими полями и доп. Таблицы с доп. Полями

я не уточнил что в родительских сущностях идет Collection<Attachment> my bad

типо CommentAttachment, MessageAttachment и тд?

в эту сторону кстати вроде можно посмотреть

Comment --\ Message -------> Attachment Post ----------/

Comment --\ Message -------> Attachment Post ----------/

Проблема в обратной стороне связи, что хочетя из атачмента иметь простой доступ

Проблема в обратной стороне связи, что хочетя из атачмента иметь простой доступ

Зачем? Это же неправильно

Корневая сущность - не аттачмент

да не то что бы, меня и односторонний доступ устроит

Зачем? Это же неправильно

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

я не уточнил что в родительских сущностях идет Collection<Attachment> my bad

Например, есть блог и новости. У них общие поля "Тайтл" "Контент", но у блога есть автор, а у новостей нет. В общей таблице у тебя тайтл и контент, а в таблице блога только автор

такое в Доктрине есть

Вообще ормы - зло. Отучивайтесь

Например, есть блог и новости. У них общие поля "Тайтл" "Контент", но у блога есть автор, а у новостей нет. В общей таблице у тебя тайтл и контент, а в таблице блога только автор

это лишнее

можно сделать и через single table вроде

такое в Доктрине есть

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

http://jstructure.com/post/doctrine-entity-extending/

single table это изменение схемы, если добавится еще одна корневая сущность

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

https://habr.com/ru/articles/741772/

single table это изменение схемы, если добавится еще одна корневая сущность

Там просто как раз дескриминатор мап (ваш type), а дополнительное поле натравить на type_id, возможно это прокатит

Особенно если не придерживаетесь валидности схемы (ручные миграции)

а возможно и валидная схема будет

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

Чот кажется лучше наследованием (по правилам доктрины) это сделать Через дескриминаторы - очень странный дизайн. Логику этой сущности придётся через switch case делать, зачем?

single table это изменение схемы, если добавится еще одна корневая сущность

Тегнул в соседнем чате как раз на эту тему)

Чот кажется лучше наследованием (по правилам доктрины) это сделать Через дескриминаторы - очень странный дизайн. Логику этой сущности придётся через switch case делать, зачем?

Наследование - имеешь виду MappedSuperclass?

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

Ну и типо сущность пост знает что её файлы - это файлы поста, а вот сам Attachment не знает что он файл поста, нужно каждый раз сверятся

Наследование - имеешь виду MappedSuperclass?

как в доктрине принято

Там есть разные типы наследвания

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

Это решается чистым sql