Hey!

I see that this is your first PR. That is great! Welcome!

Symfony has a contribution guide which I suggest you to read.

In short:

• Always add tests
• Keep backward compatibility (see https://symfony.com/bc).
• Bug fixes must be submitted against the lowest maintained branch where they apply (see https://symfony.com/releases)
• Features and deprecations must be submitted against the 7.2 branch.

Review the GitHub status checks of your pull request and try to solve the reported issues. If some tests are failing, try to see if they are failing because of this change.

When two Symfony core team members approve this change, it will be merged and you will become an official Symfony contributor!
If this PR is merged in a lower version branch, it will be merged up to all maintained branches within a few days.

I am going to sit back now and wait for the reviews.

Cheers!

Carsonbot

Thanks @nicolas-grekas for the reviews. I applied the suggested changes. I also realized it uses $this->defaultContext instead of raw values so I refactored it a bit at this point (I hope it doesn't bother 😅 )

Also could you share your thoughts about the goal of this PR please? 🙏 I'm quite unsure this is the right approach for this problem.

I'm also unsure whether this should be handled by the decoder (right now we have a workaround with a custom normalizer looking at specific keys).

we have a workaround with a custom normalizer looking at specific keys

So you figured out a way that doesn't require changing the component? then it might be the best way, because as you spotter, defining which tags in the xml tree would need this arrayification is tricky. A normalizer looks like a better place to me.

We found a workaround, but that's not exactly what I would expect from the component.

Here's the workaround we ended with, just as information:

public function denormalize(mixed $data, string $type, ?string $format = null, array $context = []): mixed
{
    // If the first element is not an array, wrap it in an array
    if (! is_array(reset($data['plans']))) {
        $data['plans'] = [$data['plans']];
    }

    // The return thing
}

It works in our specific use case (which is why we didn't make a generic normalizer with context option and all), but I find it odd that there are no ways of telling "this XML tag should always be treated as a collection". I mean, it makes more sense to me to be handled by a decoder option, as it is (at least it's what I understand for now) directly related to the XML format. I might be wrong still.

However if I'm right (that it should be handled by the decoder), I can also understand that it would be too tricky to be handled in the decoder and that the maintainers refuses to maintain such a feature.

On the other hand, if you consider it can be added, I'd gladly work on a better implementation and look for more edge cases etc.

EDIT: What I'm trying to say is that, as I user, I'd like to have an easy option for this when dealing with XML. But I also understand that, for maintaining reason, it would be better handled in userland code as it could lead to some unwanted behavior.

I was also looking for something like this, great 👍
Hope this will be implemented in the coming Laravel updates

I was also looking for something like this, great 👍 Hope this will be implemented in the coming Laravel updates

Not related to Laravel. However you can still use it as a dependency as the component is just like any other library.

I was also looking for something like this, great 👍 Hope this will be implemented in the coming Laravel updates

Not related to Laravel. However you can still use it as a dependency as the component is just like any other library

I know,

Indeed this is my case 👍

You are using only the encode/decode functions, right?

Because for my project when i got something like

<order_rows>
    <order_row></order_row>
</order_rows>

I use #[SerializedPath("[order_rows][order_row]")]

@Hanmac what if your XML ends up looking like this:

<order_rows>
</order_rows>

Does it handle it well? 🤔

@Hanmac what if your XML ends up looking like this:

<order_rows>
</order_rows>

Does it handle it well? 🤔

That should be skipped

the only problem i have with this approach, (or in general) are empty collections when normalizing/encoding:

  #[SerializedPath("[order_rows][order_row]")]
  protected array $rows = [];

if for some reason, the rows are empty, than current AbstractObjectNormalizer does normalize it to this:

[
'order_rows' => [
  'order_row' => []
]
]

which then the Encoder does turn into this:

<order_rows>
    <order_row />
</order_rows>

for this to work better, i added a Normalizer that turns empty arrays into null and then i have AbstractObjectNormalizer::SKIP_NULL_VALUES enabled to remove them.

i think i mentioned them in another ticket before, might need to create a new one => #58768

Hey
I waited a bit and forgot about this PR. I notice the milestones have been updated since. Any feedback or interest in going further (working on how to define related tags for example, as suggested by @mtarld )?
I'm still up to work on this 👍