feat(doctrine): new hook for entity/document transformation #6919
Conversation
…tityclass-transform # Conflicts: # tests/Behat/DoctrineContext.php
mrossard
changed the title
| @@ -22,6 +22,7 @@ class Options implements OptionsInterface | |||
| */ | |||
| public function __construct( | |||
| protected mixed $handleLinks = null, | |||
| protected mixed $transformModel = null, | |||
There was a problem hiding this comment.
I like the feature, I think it'd be a great fit with #6801 best would be that when the mapper is installed, we add a default transformer that uses the object mapper!
I'm just not a fan of the naming but this one is hard haha. A few ideas:
- transformEntityToResource
- entityToResourceMapper
- mapper
- resourceTransformer
I think that it's missing a way to transform a resource to an entity when persisting data (POST/PATCH) WDYT?
Last but not least, you should work on an interface that'd be used to autoconfigure the "transformEntityLocator", it would surely help with naming things.
There was a problem hiding this comment.
I like the feature, I think it'd be a great fit with #6801 best would be that when the mapper is installed, we add a default transformer that uses the object mapper!
I'm just not a fan of the naming but this one is hard haha. A few ideas:
* transformEntityToResource * entityToResourceMapper * mapper * resourceTransformer
Yeah, i'm not a fan of it either - tried to find a name that works with both entities or documents, but model feels lame, and I didn't want to use mapper to avoid confusion with what you're preparing on that side.
How about resourceBuilder or something along those lines?
I think that it's missing a way to transform a resource to an entity when persisting data (POST/PATCH) WDYT?
Wouldn't it be redundant when we already have entityClass + handlelinks?
Last but not least, you should work on an interface that'd be used to autoconfigure the "transformEntityLocator", it would surely help with naming things.
I'll look into this. I was not sure about that part, actually i was wondering (and i actually left a comment in the code) if this locator trait is better by itself or if it should be merged with LinksHandlerLocatorTrait into a common OptionsHooksLocatorTrait of some sort...WDYT?
Currently when using stateOptions to specify the entityClass (or documentClass) for your custom ApiResource, the standard StateProviders do exactly what you need most of the time, but you still often need to write custom providers to correctly map the entity/document to the actual resource.
This adds the possibility to specify a hook (the same way you specify custom a handleLinks method) to transform the doctrine entity or document into the desired ApiResource without having to write a full custom StateProvider.