Open themark147 opened 1 year ago
Quickly looking at the symfony
context - it looks like it like an associative array - so most probably it can be easily extended to add all JMS options.
In the opposite way for sure not all Symfony context options can be reflexed in JMS - for example DateTime format.
For me it makes sense to start with limited scope and add missing features in the future :)
Using FOSRestBundle
for some inspiration here wouldn't be a bad idea. It has an adapter layer to support both serializer implementations.
But, and this is a big but, it also has its own serialization context layer which can handle mapping a subset of similar context configs and dumping the rest through an attributes array.
And then, as pointed out, there are just some incompatibilities between the way things operate between the two serializers that just can't be mapped without changes in the JMS serializer (neither the DateHandler
nor SymfonyUidHandler
consider the context for formatting, those have to be done through the type configuration or a class level default).
The other big thing that would need a mapping layer would be the exceptions as if the Symfony SerializerInterface
is being typehinted against, it'd be a bit weird to have to know to catch exceptions from an alternative implementation.
Hi,
Symfony 6.3 brings great feature https://symfony.com/blog/new-in-symfony-6-3-mapping-request-data-to-typed-objects and new RequestPayloadValueResolver
Im thinking about create some adapter from JMS serializer to Symfony serializer to easily use that new resolver. I created some easy adapter but I have problem with context. I am not sure if its even able to do that and support all features from JMS serializer and adapt them do symfony serializer
thanks for any answers