/** * @ORM\Id * @ORM\Column(type="uuid", unique=true) * @ORM\GeneratedValue(strategy="CUSTOM") * @ORM\CustomIdGenerator(class="\Ramsey\Uuid\Doctrine\UuidGenerator") * @OA\Property( * type="string", * format="uuid" * ) */ private $id;

похоже, надо описать формат uuid

@Friendsys Убери с геттера описание доки,

секунд

убрал, все то же 🙁

это очень странно

в общем

написал свой PropertyDescriber

и заработало

написал свой PropertyDescriber

есть ощущение что парсер не видит описание свойства, а ты испортировал аннотацию в сущность ?

сделал по аналогии с DateTime класс дескрайбера

class UuidPropertyDescriber implements \Nelmio\ApiDocBundle\PropertyDescriber\PropertyDescriberInterface { use NullablePropertyTrait; /** * @inheritDoc */ public function describe(array $types, Schema $property, array $groups = null) { $property->type = 'string'; $property->format = 'uuid'; $this->setNullableProperty($types[0], $property); } /** * @inheritDoc */ public function supports(array $types): bool { return 1 === count($types) && Type::BUILTIN_TYPE_OBJECT === $types[0]->getBuiltinType() && is_a($types[0]->getClassName(), UuidInterface::class, true); } }

и в services.yml: App\Utils\UuidPropertyDescriber: tags: [ { name: nelmio_api_doc.object_model.property_describer } ]

Ага, спасибо. Поправил, но это не спасло от ошибки

бракую исправление, ток что протестил, работает и ьез jsonContent

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

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

нет, зачем

а как верно? Вот есть у меня админка, хочу туда кидать запросы по api и создавать сущности, к примеру

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

есть контроллер для администрирования сущности, который crud реализует через формы

вряд ли он подойдет?

вряд ли он подойдет?

Если вы его используете и хротите описать докой то почему нет

Если вы его используете и хротите описать докой то почему нет

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

или делать отдельные методы для api?

но тогда дублирование функционала (crud) получается

или делать отдельные методы для api?

Отдельные

а, ну значит верно мыслю )

но тогда дублирование функционала (crud) получается

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

это новое ) А куда выносить?

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

мидлвару делать?

мидлвару делать?

https://www.youtube.com/watch?v=eU4ajVB9Lz4

спасибо, погляжу сейчас )

https://www.youtube.com/watch?v=eU4ajVB9Lz4

То есть, писать логику в Entity, получается, надо? ) То, что с Entity может происходить

То есть, писать логику в Entity, получается, надо? ) То, что с Entity может происходить

Верно. Это и называют ООП. Про это весьма подробно рассказано там в https://elisdn.ru/blog/142/structs-or-objects

будем образовываться. В общем, логика, которая может происходить с Entity, пишется в Enitty, бизнес логика пишется где-то-между контроллерами и энтити, в контроллерах первичная валидация, редиректы и вызовы бизнес-логики. Звучит приятно, попробуем с этим взлететь )

чтобы Psalm так не ругал что надо делать?

MissingConstructor я вообще не исползиваю конструктор в этом сущности

чтобы Psalm так не ругал что надо делать?

Задать значение по умолчанию, или создать конструктор в котором указать поле minPrice

значить по правилам нельзя писать так /** * @ORM\Column(name="title", type="string", length=64) */ private string $title;

надо private string $title = ''; ?

надо private string $title = ''; ?

Чтобы psalm не ругался - да

чтобы Psalm так не ругал что надо делать?

/** * @psalm-suppress MissingConstructor */ или прописать в конфигах игнор на папку с сущностями или писать нормально)))

/** * @psalm-suppress MissingConstructor */ или прописать в конфигах игнор на папку с сущностями или писать нормально)))

Писать нормально как я приводил пример выше?

Писать нормально как я приводил пример выше?

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

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

Понятно спасибо😊

Доброго утра. А почему в Entity может автовайринг не работать? Хочу присобачить сериалайзер, прописал свойство, в конструктор добавил аргумент, в сервисах прописал аргумент - пробую обратиться - получаю Typed property App\Entity\Widget::$serializer must not be accessed before initialization. С другими классами прокатывает, с теми, что в Entity - нет.

Доброго утра. А почему в Entity может автовайринг не работать? Хочу присобачить сериалайзер, прописал свойство, в конструктор добавил аргумент, в сервисах прописал аргумент - пробую обратиться - получаю Typed property App\Entity\Widget::$serializer must not be accessed before initialization. С другими классами прокатывает, с теми, что в Entity - нет.

В services.yaml в настройках отключено?

В services.yaml в настройках отключено?

имеете в виду, в exclude?

Да

и правда... Спасибо, вырежу сейчас попробую )

и правда... Спасибо, вырежу сейчас попробую )

Чавооо, какой автовайринг у сущности😳

а как? )

а как? )

Какую задачу ты хочешь решить?

а никак, у сущностей не должно быть сервисов S for SOLID

у сериализаций контексты шмонтексты, вот это вот всё, сущности про такое знать не положено

Всем привет У кого-нибудь есть полный гайд по правильной установке симфони на опенсервер? Например, включая как использовать nginx, а не встроенный сервер symfony и т. д.

Какую задачу ты хочешь решить?

Хочу запилить объект, как из доклада : ) И чем сущность не объект, с которым можно работать?

Верно. Это и называют ООП. Про это весьма подробно рассказано там в https://elisdn.ru/blog/142/structs-or-objects

Может быть, конечно, я неправильно понял

но тогда где создавать этот объект и зачем мне плодить сущности?

Всем привет У кого-нибудь есть полный гайд по правильной установке симфони на опенсервер? Например, включая как использовать nginx, а не встроенный сервер symfony и т. д.

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

но тогда где создавать этот объект и зачем мне плодить сущности?

Сервис-контейнер придуман для сервисов, а не для сущностей. Сущности только хранят и управляют своими данными. Если сущности понадобился какой-то сервис, то передавайте его в метод сущности вроде $entity->method(..., $serializer) и используйте его там налету, а не присваивайте в конструкторе. А так сериалайзер по своему назначению обычно используется выше на уровне контроллера, поэтому обычно ему не место в сущности.

Сервис-контейнер придуман для сервисов, а не для сущностей. Сущности только хранят и управляют своими данными. Если сущности понадобился какой-то сервис, то передавайте его в метод сущности вроде $entity->method(..., $serializer) и используйте его там налету, а не присваивайте в конструкторе. А так сериалайзер по своему назначению обычно используется выше на уровне контроллера, поэтому обычно ему не место в сущности.

Но контроллер же только для вызова команд? Мне, получается, нужно сделать отдельный слой для бизнес-логики в приложении? Этакий объект, в котором производить действия и который будет использовать сущность?

правда, очень хочется разобраться 🙂

Но контроллер же только для вызова команд? Мне, получается, нужно сделать отдельный слой для бизнес-логики в приложении? Этакий объект, в котором производить действия и который будет использовать сущность?

Да, как в докладе выше

Да, как в докладе выше

пойду еще раз пересмотрю )

угу, понял, где ошибся. У меня первая и вторая части доклада спутались :)

пойду еще раз пересмотрю )

Там как раз пять разных контроллеров заполняют одну и ту же команду из формы или сериалайзера. И хэндлер команды как раз инжектит другие сервисы и использует сущность.

Там как раз пять разных контроллеров заполняют одну и ту же команду из формы или сериалайзера. И хэндлер команды как раз инжектит другие сервисы и использует сущность.

да, как раз смотрю

да, как раз смотрю

Этот доклад подготовлен по коду моего большого проекта https://youtu.be/j2hvBhxTSuQ

пойду еще раз пересмотрю )

на пятый раз картинка сложится )))

точно )))

да, как раз смотрю

А если интересует связка API с фронтендом, то более современный вариант я использую в новом проекте с 13-го эпизода. С обновлённым кодом всех команд, хэндлеров и сущностей.

А если интересует связка API с фронтендом, то более современный вариант я использую в новом проекте с 13-го эпизода. С обновлённым кодом всех команд, хэндлеров и сущностей.

Да, я уже полюбопытствовал. Про Vue.js не планируете что-нибудь? Вроде он сейчас "модный молодежный" )

Да, я уже полюбопытствовал. Про Vue.js не планируете что-нибудь? Вроде он сейчас "модный молодежный" )

Разные весовые категории https://t.me/oop_ru/151827

Разные весовые категории https://t.me/oop_ru/151827

Еще такой вопрос (я, конечно, сам проверю, когда до этого дойду) - При такой записи что будет делать Доктрина? Как она определит, что надо создать соответствующие поля в БД? Как определит тип, как прописать Constraint и прочие ништяки?

а, вижу про ConfirmToken, извиняюсь

вопрос снят

только в докладе нет окончания - как все же подружить этот Lot, который весь правильный и созданный в конце Lot, который сущность

только в докладе нет окончания - как все же подружить этот Lot, который весь правильный и созданный в конце Lot, который сущность

Доклад про донести идеи, а не обучить как пошагово построить приложение)