[Serializer] when normalizing, order the properties in a way controllable by the user

[dkarlovi]

Description
Currently, when normalizing, the serializer seems to order the properties in the same way it discovers them (guessing, reflection-based?). If possible, ot would make sense to use the order as supplied by the user.

Example

With classes:

class A {
    public $a;
    public $b;
    public $c;
}

class B extends A {
    public $d;
    public $e;
}

with config:

<?xml version="1.0" ?>
<serializer>
    <class name="B">
        <attribute name="a"/>
        <attribute name="b"/>
        <attribute name="c"/>
        <attribute name="d"/>
        <attribute name="e"/>
    </class>
</serializer>

I would expect it to come out normalized in the exact order specified in the mapping.

Instead, it comes out as:

d:
e:
a:
b:
c:

[Einenlum]

@dkarlovi I never encountered a case where the order of the properties mattered, in a json, yaml or xml.
Do you have an example?

[dkarlovi]

@Einenlum The order is for humans. If you have an API (say, built on API Platform), it makes sense for you to be specific in the order of the properties (for example, the more common ones on top, group similar properties together, etc).

Since the order exists and is not arbitrary anyway (it doesn't change between refreshes), it would make sense to allow the user to control it.

[Dranac]

If you serialize data as CSV you'll expect to be able to choose the order of the fields (at least an order you can expect or an explanation about the generated order).

In my case i have something like :

$serializer->serialize(
    $collectionOfData,
    'csv',
    [
        'attributes' => [
            'id',
            'name',
            'description',
            'year',
            'actors'       => [
                'type',
                'name',
            ],
            'location'     => [
                'address', 
                'city', 
                'country', 
                'zipCode',
            ],
            'sizing'       => [
                'length',
                'volume',
                'surface',
                'outflow',
                'other',
            ],
        ],
    ]
);

It will generate a csv like this :

id, name, description, location.address, location.zipCode, location.city, location.country, sizing.length, sizing.volume, sizing.surface, sizing.outflow, sizing.other, year

Why does sizingkeeps its order while location does not ?
Why does field yeargoes at the end while id,name,description are at the right place ?

[maidmaid]

@Dranac here, a workaround to generate your csv with the ordered fields (described in the private orderproperty) :

namespace App\Serializer\Normalizer;

use App\Entity\Foo;
use Symfony\Component\Serializer\Normalizer\NormalizerInterface;
use Symfony\Component\Serializer\Normalizer\ObjectNormalizer;

class CsvFooNormalizer implements NormalizerInterface
{
    private $normalizer;

    private $order = ['a', 'b', 'c'];

    public function __construct(ObjectNormalizer $normalizer)
    {
        $this->normalizer = $normalizer;
    }

    public function normalize($objects, $format = null, array $context = array()): array
    {
        $data = [];
        foreach ($objects as $object) {
            $ordered = array_merge(array_flip($this->order), $this->normalizer->normalize($object, $format, $context));
        }

        return $data;
    }

    public function supportsNormalization($data, $format = null): bool
    {
        return is_array($data) && $data[0] instanceof Foo && 'csv' === $format;
    }
}

[dkarlovi]

@maidmaid creating a custom normalizer for each class you want to serialize just to manually set the order is not great, not to mention the performance implications this approach might have, doesn't seem like a good workaround, let alone what I'd consider a solution.

[brooksvb]

+1 this issue because I am in the exact situation: Wanting to reorder the properties for a CSV.

[HRvojeIT]

@dkarlovi I never encountered a case where the order of the properties mattered, in a json, yaml or xml.
Do you have an example?

Amazon MWS Feed xml format!

[gomcodoctor]

Same issue here.. need to have specific order of properties in csv

[Surf-N-Code]

+1

Workaround: Change the order of your getters and setters within your entity.
https://stackoverflow.com/a/48442956/9036543

[arjanfrans]

Our system has clients which require a fixed order of XML fields. They are using some funny XML parsers or configurations which rely on the order. Unfortunately we have to consider the order. It worked fine using the JMS parser before, which supports this feature. After upgrading to Symfony parser we had set the order of getters and setters right (as mentioned by @Surf-N-Code).

However, this leads to some complications when for example extending a class. If I want to have a different order for a field in my child class, I'd have to copy all the functions.

It would be nice to see a solution like the JMS has, an annotation which allows you to specify the order.

[dunglas]

We could use the order defined in XML files, but it will not work for annotations (as annotations use the reflection API under the hood, the order will be the same as currently).

Also, the order doesn't matter when serializing JSON documents (except for humans) because by the spec JSON objects are unordered.

The order matters however only if you use XML or CSV.

To be honest, I think that when the order matters and isn't the same as the one of the properties (or accessors) in the class, using a dedicated DTO matching the excepted output would be cleaner than introducing an "order" or a "weight" key on the annotation, but I'm not strongly opposed to adding such key anyway.

Regarding other config formats than annotations, I´le not sure if changing the order to match the one in the config file would be allowed by our BC promise.

[dkarlovi]

@dunglas we can always opt in. But also, since this order is not deliberate, it does seem like it wouldn't be part of it.

[dunglas]

Why isn't it deliberate? Having the same order than the one is the class looks rational to me.
Opt-in will require to introduce an "order" attribute even in XML and YAML (which is fine, I guess).