еще можно прикрутить тайпы от доктрины и большая часть мапится ей же

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

Наверное там подумали что зачем это городить в ДБАЛ если ты скорее всего будешь делать свой ДТО

и в нем себе сконвертишуешь, возможно даже используя \Doctrine\DBAL\Connection::convertToPHPValue($value, $type)

чисто апликейшн специфик фича

и в нем себе сконвертишуешь, возможно даже используя \Doctrine\DBAL\Connection::convertToPHPValue($value, $type)

Ну вот я про это говорил, но нужен тип

Тип нужен если ты хочешь какой-то универсальный способ конвертации написать

А если ты пишешь ДТО, то типы известны

например MyDto::create($row, $conn);

ну чисто как пример

Тип нужен если ты хочешь какой-то универсальный способ конвертации написать

Ну вот не хочется например дто писать, и типы вручную переводить

Тогда в чем вопрос? Почему ДБАЛ не хранит в БД данные о типе столбца?

Потомушта )

Тогда в чем вопрос? Почему ДБАЛ не хранит в БД данные о типе столбца?

Потому что не все БД и драйвера имеют такую фичу

А дбал это асбтракция

Т.е фича - получить инфу о данных вместе с запросом на селект

Я вообще не знаю почему эти типы не вынесены в ОРМ

зачем они в дбал

Если она их никак не использует

Я вообще не знаю почему эти типы не вынесены в ОРМ

Потому что можно их заюзать мимо ОРМ, я вот как раз юзаю

И как ты информацию о типах хранишь?

Получаю тип из пдо, маплю этот тип на тип доктрины - получаю тайп кастер от доктрины

Не все базы поддерживают хранение метаионформации о типе?

Не все базы поддерживают хранение метаионформации о типе?

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

А понял ты мапишь тип БД на тип доктрины руками

Я думал ты сразу храниш тип доктрины рядом где-то в БД

А понял ты мапишь тип БД на тип доктрины руками

Ну как руками, обертка )

в каком-то там комент поле у столбца или что-то такое

в каком-то там комент поле у столбца или что-то такое

понял да

Кто знает как лучше закрыть стейдж от кровлеров?

Закрыл через basic auth, но пошли проблемы с апи, в котором теперь тоже надо этот Бейсик аус передавать

И конфликт с обычной jwt авторизацией

Еще этот нгинкс настолько конченый в настройках что там сделать что-то сложнее отлай статику то еще приключение

Кто знает как лучше закрыть стейдж от кровлеров?

Закрой всё, кроме апи методов

Хотел так сделать да, но нгинкс чет сопротивляется

Лыжи не едут чет

А нгинкс то зачем?

В конфигурации никак?

Прям симфой?

Ну, да)

Она умеет басик аус?

Конечно)))))

Чет я в эту сторону не подумал

Хммсммс

security изучите)

Да я то знаю, простл не подумал как-то что она обычный басик аус может

Тупанул

Если не разберётесь - маякните

У меня есть, позавчера так закрывал)

Пока не у компа только

Привет всем, можете кто подсказать по формам. Есть форма, на нее надо добавить два радио-баттона. Хотелось бы сделать отдельными полями c типом RadioType, но не совсем понятно как вообще с таким работать (в твиге нужно выводить их отдельно как я понимаю через form_widget, c кастомной версткой) $builder ->add('option1', RadioType::class, [ 'mapped' => false, 'required' => true, ]) ->add('option2', RadioType::class, [ 'mapped' => false, 'required' => true, ]) Есть подход с ChoiceType и в цикле выводить уже в шаблоне, этот вариант простой, он работает, но не подходит в данном случае. Есть ли вообще нормальный подход раздельно с этими радио-баттонами работать?

Ты пробовал в профайлере смотреть на форму?

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

Просто рисуешь нужные элементы нужными твиг фциями и всё

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

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

Если просто не большая админка?

тогда vue через CDN подцепить и то приятнее чем в шаблонах ковыряться

Если просто не большая админка?

Тогда есть всякие там SonataAdmin, для максимально простого и стандартного отличная вещь. Ну, конечно превращается в ад, если нужна хоть какая-то кастомизация...

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

Согласен, но пока времени это переделать на vue/react нет (да и никто не видит большого смысла, так как это админка)

Всем привет! Может кто-то помочь с данной проблемой? https://stackoverflow.com/questions/75430811/why-in-children-array-the-parent-property-does-not-serialize

Всем привет! Может кто-то помочь с данной проблемой? https://stackoverflow.com/questions/75430811/why-in-children-array-the-parent-property-does-not-serialize

Chatgpt?

Chatgpt?

Советует юзать MaxDepth and Groups

Можно же на человекопонятном объяснить проблему

Можно же на человекопонятном объяснить проблему

Суть в том, что симфони берет и конвертит объект в IRI строку. Но мне нужен объект, а не IRI. Я смотрел через xDebug нормализатор и было видно как симфони нормализует объект. Но на выходе я получаю все равно IRI

А какой объект нужен? Предположим, что у нас есть объект X, он имеет вид: { id: children: [ { ... parent: - здесь должен быть опять объект X } ] Получаем рекурсивный бесконечный цикл. И maxDepth тут никак не может помочь, потому что X снаружи должен содержать X внутри, и это только при уровне вложенности 1

А какой объект нужен? Предположим, что у нас есть объект X, он имеет вид: { id: children: [ { ... parent: - здесь должен быть опять объект X } ] Получаем рекурсивный бесконечный цикл. И maxDepth тут никак не может помочь, потому что X снаружи должен содержать X внутри, и это только при уровне вложенности 1

Ну.. во вложенном объекте X можно было бы просто убрать children и тогда не было бы бесконечной вложенности

Просто.. я хотел в одном запросе получить весь список Item'ов и чтобы у каждого был children и parent свойства. Но есть другой вариант. Делать запрос на каждый клик и получать все что нужно для конкертного item'а

А почему в качестве parent нельзя просто родительский объект брать?

На фронте есть метод, который рекурсивно проходит по всем parent'ам и собирает stack из titl'ов

и потом делаю .join(' > ') и получаю что-то вроде этого

Hi guys how to add blank line after the if clause the end curly braces for example if(true){ return ; } //this blank line means $var="value" in phpcs Fixer

Hi guys how to add blank line after the if clause the end curly braces for example if(true){ return ; } //this blank line means $var="value" in phpcs Fixer

I used the standard phpcs fixer library

which rule should I use?

Всем привет! Подскажите, как вы используете интерфейсы для сервисов? У меня три варианта: 1) Для каждого сервиса пишется свой интерфейс 2) Не писать интерфейсы 3) Писать общие интерфейсы. Например, многие сервисы имеют методы getAll() и getById(). Третий вариант мне нравится, но меня вот что коробит. Если такой интерфейс написать, то там нельзя будет указать возвращаемый тип, потому что метод getById в UserService вернет User, а в CarService вернет Car. Дальше мне приходит мысль объединить все entity общим интерфейсом, например EntityInterface и его возвращать в методе getById в интерфейсе для сервисов. Но тут возникает вопрос: нормально ли, что в интерфейсе будет одно возвращаемое значение, а в реализации другое? Поделитесь, пожалуйста, как вы используете интерфейсы

/*Interface*/ interface ServiceInterface { public function getById(int $id): EntityInterface; } /*Entity*/ class User implements EntityInterface /*Service*/ final class UserService { public function getById(int $id): User { return $this->userRepository->find($id); } }

Ну и такая же проблема с какими-нибудь мапперами. Везде метод fill, который принимает entity и DTO и заполняет одно другим. Отличаются только имена классов.

Какие минусы в таком подходе?

Всем привет! Подскажите, как вы используете интерфейсы для сервисов? У меня три варианта: 1) Для каждого сервиса пишется свой интерфейс 2) Не писать интерфейсы 3) Писать общие интерфейсы. Например, многие сервисы имеют методы getAll() и getById(). Третий вариант мне нравится, но меня вот что коробит. Если такой интерфейс написать, то там нельзя будет указать возвращаемый тип, потому что метод getById в UserService вернет User, а в CarService вернет Car. Дальше мне приходит мысль объединить все entity общим интерфейсом, например EntityInterface и его возвращать в методе getById в интерфейсе для сервисов. Но тут возникает вопрос: нормально ли, что в интерфейсе будет одно возвращаемое значение, а в реализации другое? Поделитесь, пожалуйста, как вы используете интерфейсы

Не пишу интерфейсы тем более для сервисов. Ладно ещё репозитрий (хотя тоже холивар), но какой профит от сервиса?

Интерфейс сервиса, интерфейс репозитория. Скоро интерфейс дто делать начнём