IBX-8190: Add Symfony's Serializer support

[barw4]

🎫 Issue	IBX-8190

Related PRs:

https://github.com/ibexa/scheduler/pull/111

Description:

AdapterNormalizer

A new normalizer with low priority is implemented called AdapterNormalizer that handles data normalization or visiting data using the existing visitors. Currently, the visitors are prioritized over incoming (new) normalizers.

Unfortunately, the problem is that in order to visit value objects the Visitor and Generator have to be created and passed as arguments to ValueObjectVisitor instance.

        $valueObjectVisitor->visit($visitor, $generator, $object);

Ibexa\Contracts\Rest\Output\ValueObjectVisitorDispatcher

It is deleted now and the responsibility for finding a proper visitor is moved to the newly introduced ValueObjectVisitorResolverInterface.

Ibexa\Contracts\Rest\OutputVisitor

The visitValueObject method has to behave exactly the same as before as it's used throughout the app so we should keep BC here. I don't think we can change it to use normalizer as it uses the original Visitor's generator.

Concept made by Paweł.

For QA:

TBD

Documentation:

TBD

[Steveb-p]

Since I consulted this approach I'll give some explanations too.

Whole concept relies on using Serializer as primary entry point for data normalization.

While analyzing how Visitors worked with Generator, it became apparent that Generator basically serves as a Data Container that changes it's internal "pointer" as instructed by Visitor. This is "shared" between XML and JSON Generators, with the difference being that XML outputs it's state during this process.

So, since the primary difference between Symfony normalization and our Visitor's processing is that Symfony returns data and Visitors pass around Generator (as data storage), we can give Visitors a "fake" Generator - which whole purpose is to store data - and use it's state at the end as normalization result. This results in both processes behaving in a similar way.

[alongosz]

A lot of solid work 💪

Some remarks & questions:

[alongosz]

The first line doesn't make sense here, as it's immediately overridden by the next line.

[alongosz]

Suggested change

	* @return array<string, mixed>
	* @return array<string, mixed>
	*
	* @throws \Symfony\Component\Serializer\Exception\ExceptionInterface

[alongosz]

Have you tried to use assertXmlStringEqualsXmlFile instead?

[barw4]

Yes and I think this method expects clean xml, without:

<?xml version="1.0" encoding="UTF-8"?>

because I'm getting:

Could not read <?xml version="1.0" encoding="UTF-8"?>

with it.

[alongosz]

What's the source of/reason for that change?

[barw4]

The reason for this is that startHashElement does not support multiple elements of the same name, just like Json Generator. The proper way to handle this would be to use the startHashElement with conjunction of the startList like it's done for example in the ContentFieldValidationException visitor:

        $generator->startHashElement('errorDetails');
        $generator->startList('fields');

We are imo safe here with this change because our visitors are both handling Json and Xml and if we had something like this in some visitor:

        $generator->startHashElement('elements');

        $generator->startValueElement('element', 'element value 1', ['attribute' => 'attribute value 1']);
        $generator->endValueElement('element');

        $generator->startValueElement('element', 'element value 2', ['attribute' => 'attribute value 2']);
        $generator->endValueElement('element');

        $generator->endHashElement('elements');

JSON output would be also broken which was never the case.

[sonarcloud]

Quality Gate passed

Issues
4 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud