Dto mappers - new layer
We need to build new layer, which will be responsible for converting entities to dtos (and reverse). We have this conversion defined directly in all service implementetions (AbstractReadWriteDtoService) and this brings this issues:
- our conversion isn't called for embedded entities (standard mapper conversion is used there) - this can lead to really unpredicted behavior (e.g. #969)
- we cannot call conversions manually - conversion is defined in implementation of AbstractReadWriteDtoService not in interface. We need to call transformations independently by services for diferrent entities (e.g. see workaround in DefaultIdmAutomaticRoleAttributeService#getIdentitiesForAutomaticRole).
- dto mappers will be registered the same way as dto lookups (with same benefits)
- dto mapper manager will be created the same way as LookupService (with same benefits)
- manager will be injected into services (respectively in AbstractReadWriteDtoService) and called in current 'toDto' and 'toEntity' methods
- manager will be injected and used in ModelMapperConfig configuration.
#7 Updated by Radek Tomiška 2 months ago
- Status changed from In Progress to Needs feedback
- Assignee changed from Radek Tomiška to Vít Švanda
- % Done changed from 0 to 90
New layer is implemented and is used from model mapper converters, aduit and for converting owner into eav form values.
+ api improvements to implement custom dto mapper easier with context is available (and used for form values):
Could you provide me a feedback, please?