шо именно? хендлер или сам мапинг через doctrine inheritance?

Маппинг

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

точнее если для двух разных мапингов классов, например User.orm.yaml и Customer.orm.yaml указана table: user

У тебя должна быть отдельно юзер, отдельно кастомер, кастомер ссылается на юзера

У тебя должна быть отдельно юзер, отдельно кастомер, кастомер ссылается на юзера

а, типа через композицию?

так то я и пытаюсь сделать. сделал с помощью Doctrine inheritance mapping) у меня Customer, NotActivatedCustomer, DeletedCustomer и BannedCustomer, со своими методами/филдами каждый. только вот это не супер пупер юзать doctrine inheritance mapping как я понимаю для этого? потому что если не юзать такой тип мапинга, то доктрина ругается, что у мапингов для разных классов (Customer.orm.yaml, DeleteCustomer.orm.yaml, etc) указана одна табличка user

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

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

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

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

грубо говоря псевдокод такой: if ($workflow->can($initiative, 'republish')) { $workflow->apply($initiative, 'republish'); } такой клиентский код у компонента state machine/workflow. а под капотом он через указанный в workflow.yaml параметр marking_store: type: 'method' property: 'status' он вызывает $initiative->setMethod($status), который и есть тот паблик метод. поэтому если случайно энтити $initiative протек куда-то кроме UseCase, в котором этот блок if($workflow->can()) then $workflow->apply() вызывается, то можно поменять статус с любого на любой, а не по логике транзишенов) поэтому я подумал, что $workflow проверки должны быть внутри сущности, а не снаружи, как у меня в UseCase, чтобы не было возможности сменить в обход с $workflow статус, а также чтобы не было паблик метода. но как агрегировать симфонийский воркфлоу безболезненно в доменную сущность, я хз. либо писать свой кастомный state machine лол, в доменном слое простигосподи, чем я точно заниматься не хочу.

Сущности не должны зависеть от инфраструктуры

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

ну или как уже написал - сделать в доменном слое доменный сервис например, который инстанцировать в сущности

Ничего в сущность не внедряется

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

Я бы абстрагироваться от этих инструментов пока

та вот да) это из беклога "задачка" у меня по сути годичной давности наверное уже )

Так в чем проблема

Имеешь ввиду забить?)

В чем суть задачи?

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

но как прокинуть внутрь энтити без внешних сетеров инжекцию симфонийского воркфлоу - хз )

СОЛИДно вроде да? инжеким нужный и радуемся. Думаю на этом остановлюсь, всем спасибо ❤️

В чем шляпа?

Минимум в названии, но думаю и в логике

В логике там тоже самое что и у тебя 🤣

and в названии не смущает?

Нет. Без него будет не то. Сухо так сказать ?

Как бы ты назвал?

Я бы сначала без воркфлоу посмотрел что можно сделать

Что именно?

Та вот иначе без Стейт машин может быть лапша из кондишенов если много статусов и тп. Хотя мб консистентность перехода можно проверять в самом классе статуса, который инжектить в энтити)

Валидатор дто, который ошибки группирует по полям

А накой хер снаружи знать, что 1) валидирует дто, 2) что группирует что-то по полям?

Потому что он: 1) валидирует дто и ничего больше. 2) группирует ошибки по полям.

Чоб и не называть так? ))) Зато понятно шо делает

Это раскрытие реализации, не имеет смысла

Потому что эти объекты и есть реализация? Их там не даром два штуки )

Что ты ждешь от класса? Валидации. Ну пох, пусть будет только Дто. Назови DtoValidator

Что делать с ошибками? Которые надо выдавать в двух вариантах

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

Может быть сделать один валидатор и например 2 трансформера/нормалайзера?

Блять... Там написано - валидатор дто. Пора учится читать ))

И потом тащить две зависимости. Я ведь так и сделал. Там в чате есть

@sc0rp10 вот такие массивы from как я понимаю указывать нельзя?

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

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