Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

adapter to symfony serializer? #928

Open
themark147 opened this issue May 23, 2023 · 2 comments
Open

adapter to symfony serializer? #928

themark147 opened this issue May 23, 2023 · 2 comments

Comments

@themark147
Copy link

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

@scyzoryck
Copy link
Collaborator

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 :)

@mbabker
Copy link
Contributor

mbabker commented May 31, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants