Use composition for Normalizers

[joelwurtz]

Q	A
Bug fix?	no
New feature?	yes
BC breaks?	no
Deprecations?	yes
Tests pass?	yes
Fixed tickets	#2355
License	MIT
Doc PR	/

This is a beginning for #2355 to use composition over inheritance in the various normalizer. Goal is to be decoupled from the ObjectNormalizer so someone can still use JSON LD / Hydra / Json API with a custom normalizer or a different implementation.

There is a lot of questions that i wonder, that's why it's far from being complete but it shows where i want to go.

Some questions i have:

• Should we have a new class instead ? (easier for depreciation)
• Does every normalizer should use composition (like i began to do) or should we add a generic decoupling instead (not sure if it will be easier)
• Some behavior may be not available in the sub normalizer (like object to populate) is there a way to enforce this or should we just tell the user to take care of this with documentation ?

[joelwurtz]

Also began to split the AbstractItemNormalizer, as you can see i extract the context initlization into its own normalizer and also the data transformation into its own normalizer.

[dunglas]

Let's see where it brings us. For now I'm not sure to fully understand the changes, but the final goal is 100% legit, and we'll improve the design (next step, or parallel step, would be to the same thing in the Symfony Serializer)

[joelwurtz]

For now I'm not sure to fully understand the changes

Me neither xD, there is a lot of code that is duplicated from ObjectNormalizer and actually trying to see the little differences betweens (like iri convertion / relation normalizatiing and others stuffs)

I think a may have a way to completly remove the AbstractItemNormalizer, but this may require new methods in some interfaces.

I will try to do a first shot by creating a new way of normalization (withtout the AbstractItemNormalizer) without touching the existing implementation so we can spot / benchmark / tests behaviors in parallel.

[dunglas]

Maybe would it be easier to start refactoring the Symfony component first, then use its new extensions points that need to be created anyway. WDYT?

[joelwurtz]

I prefer to refactor it here first, since api platform normalizers are heavily based on symfony serializer system and features, having a look first at the blockers and usage when extending it to the maximum will give us a better look on how to refactor better symfony.

Also i think we can get something nice without touching symfony (but maybe i'm wrong).

[joelwurtz]

So made a lot of revert, and begin to work in a new class, i will handle deprecation at the end if final design is accepted (mainly deprecate the old class to use the new one)

ATM there is a good exemple for the JsonLdItemNormalizer

So overall design will look like this: Every feature is splitted into its own normalizer:

• ResourceClassNormalizer handle the extraction of the resource class and check if the given object can be normalized / denormalized as a resource class
• DataTransformerNormalizer handle data transformations using the DataTtransformerInterface
• No more custom AbstractItemNormalizer, it directly use the ObjectNormalizer of symfony
• Each "format" normalizers (json ld / json api / ...) add the necessary metadata to the data (like before)

Each of this normalizer use a sub normalizer to handle data, so in fact to handle json ld data it need a normalizer chain like this:

ResourceClassNormalizer -> JsonLdItemNormalizer -> DataTransformerNormalizer -> ObjectNormalizer (Symfony)

Also i believe this will allow to remove all code that need to check about handling non resource class, as someone will be able to inject its own chain of normalizer and give necessary info into the context if needed.

[teohhanhui]

@joelwurtz Just a heads up, I've changed the normalization of non-resource in #2679

[joelwurtz]

Thanks for the heads up, look better that way

[teohhanhui]

Another heads up, denormalization of non-resources also uses composition now in #2797.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[soyuka]

same reason I closed #2355 we're now watching how the symfony/symfony#51718 work progresses! thanks for the work!