Пока продолжаем старый способ закрытия по принятию MR

С другой стороны а какое еще движение сейчас у задачи может быть? Вот когда будут у задачи этапы, а уж тем паче релизы. Или хотя бы стенды будут для тестирования релизов, можно будет вытаскивать задачи на этап rc или тест, а при релизе скопом закрывать.

Прошло ревью. Может не закрывать?

Доделал. На ревью

Сделал самую суть системы в простой реализации

Отказался от сериализатора, вернулся к самостроящимся и самосворачивающимся объектам. Базовое редактирование готово. Осталось его везде заюзать.

Entity->get|setField читает и слушатель, ожидая сырой массив и после бизнес-логика, ожидая сформированный объект. И разделить это никак нельзя, не создавая новые проекси, костыли, проверки и т.д. Может все же отказаться от сериализатора, достал

Второй вопрос, как скрыть из интерфейса словаря изменение id, но позволить словарю сохранять и поддерживать id, даже когда форма меняет словарь (добавляя, например элемент) через getItems/setItems

Так же, мы при загрузке entity еще можем хуком вызвать Листенер, который подменить содержимое поля. Но в будущем мы все равно будем вызвать $project->getTaskSettings, и в этот момент мы не моежм быть уверены развернутый там объект или его json-представление. В итоге в попытке отладить редактирование объекта мы все равно скатились к тому, что объект то и дело сам себя разворачивает из массива или пакует в массив. Либо надо подключать сериализатор к энтити, либо обходится целиком без него. Либо вобще считать, что энтити выдает только raw, а объект получать из сервиса.

Symfony/Serializer не может понять какой объект класть в проперти вида

/** @var Object[] */
array $propert;

Надо или переходить на php8 и явно указывать Object[] $property;, или разворачивать в объект вручную

Ну вот в такм куцем виде система на загрузку заработала. Обратно тоже трансформирует, осталось в контроллере тыкнуть сохранение. (точнее в Filler’е).

Надо бы только подраздвинуть поле и бьютифицировать json. Из коробки этого сериализатор не умеет, или писать свой json-encoder (что ради разовой задачи удаляемого контрола - такое), или в трансформере быстро расставить переносы и пробелы.

Тут сразу стоит убрать и сложную иерархию Type-классов. Тем более что DicitionaryItem все равно не влазит в прототип для allow_add CollectionType

Продолжая идею MVP, может выкинуть сложный контрол редактирования справочника в отдельную задачу. Настройки проекта видны только мне, как единственному pm на долгое время. Чтобы не зависать неделями над сложным JS или тем паче vue.js, можно предоставить текстовое поле с красиво разложенным json, который можно вручную заполнить. А в будущем это текстовое поле будет скрытым и его будет заполнять vue-компонент

Если реализовать событие doctrine->postPersist(Entity), можно будет использовать сервисы для инициализации нашего объекта из json’а. А для универсальной мощной десериализаиции, не требующей в каждом объекте перечислять поля десериализуемые, использовать symfony/serializer

Up. Merge from last release.

Сейчас самая сложная часть, форма редактирования справочника. Либо это делать vue.js либо обычным. В любом случае я не хочу сохранения на лету, а значит надо делать иерархию форм. Видимо Общий тип JsonEntityType и от него DictionaryType и DictionaryItemType

Можно ввести свой тип JsonObject. Но тип не имеет доступа к своему описанию, потому не знает какой класс ему инстанцировать своими данными. Стандартный же тип json возвращает php-array. Либо на каждый справочник создавать тип. Либо в каждом сериализованном объекте хранить тип. Либо гидрировать в array и гетером переделывать в класс (каждый раз или меняя тип

Документация по системе лежит в [Система справочников] http://tndt.demius.ru/p/tndt/doc/sistema-spravochnikov

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