allow more control on GetSetMethodNormalizer

[tvlooy]

Here is an other attempt. You would use this as follows:

$serializer = new \Symfony\Component\Serializer\Serializer(
    array(new \Symfony\Component\Serializer\Normalizer\GetSetMethodNormalizer()),
    array('json' => new \Symfony\Component\Serializer\Encoder\JsonEncoder())
);

$callbacks = array('books' => function ($books) { return NULL; });

return new Response(
    $serializer->serialize($paginator->getRows(), 'json', $callbacks),
    200,
    array('Content-Type' => 'application/json')
);

Besides of returning NULL, you could also do things like:

$callbacks = array(
    'books' => function ($books) {
        $ids = array();
        foreach ($books as $book) {
            $ids[] = $book->getId();
        }
        return $ids;
    },
    'author' => function ($author) {
        return $author->getId();
    },
    'creationDate' => function ($creationDate) {
        return $creationDate->format('d/m/Y');
    },
);

The commit is not complete yet. But at this point I am interested in your opinions.

[stof]

this is wrong as it will allow only closures instead of allowing any callable

[lsmith77]

in general i agree that using a callback is a good solution to provide more power without complicating the API or implementation in this case.

please add a test case, this should also help illustrate how this can be used in practice.

[schmittjoh]

Note that your change breaks the API defined by the interface, i.e. someone using this method needs to type-hint the serializer implementation, not the interface.

It also adds a parameter to the public API of the serializer which will only work with one specific normalizer. What if another normalizer needs additional information, should another parameter be added to the serialize method? What about deserialization?

Bottom line is, the serializer component was simply not designed for this kind of thing. I've tried to make it more flexible before creating the bundle, but some things simply cannot be fixed in a sane way.

[tvlooy]

Would just adding a setCallbacks() to the GetSetMethodNormalizer be a better solution? That doesn't touch the API. I will try to write some tests this evening.

[schmittjoh]

That would definitely be better.

You would then need to retrieve the normalizer instance before calling serialize on the serializer which also leaves a stale taste, but I have no other solution for now.

[stof]

you should typehint the argument as array

[tvlooy]

So, this should be it then. Yet an other usage example:

$normalizer = new \Symfony\Component\Serializer\Normalizer\GetSetMethodNormalizer();
$normalizer->setCallbacks(
    array(
        'books' => function ($books) {
            $ids = array();
            foreach ($books as $book) {
                $ids[] = $book->getId();
            }
            return $ids;
        },
    )
);
$serializer = new \Symfony\Component\Serializer\Serializer(
    array($normalizer),
    array('json' => new \Symfony\Component\Serializer\Encoder\JsonEncoder())
);

return new Response(
    $serializer->serialize($paginator->getRows(), 'json'),
    200,
    array('Content-Type' => 'application/json')
);

[tvlooy]

Anything else needed for this to get pulled in?

[vicb]

what about making sure that each callback is_callable ?
that would imply removing the possibility for null value.

[tvlooy]

Hm, I like to keep it that way because I like the fact that not passing a callable will result in a warning instead of silently skipping it. You don't get that behaviour by treating it as null.

[vicb]

I was unclear: the code should throw an exception when an element is not callable, this is why null will not be supported any more (it is not a callback as the setCallbacks indicate).

They are several way to support the former behavior:

• the cb can return a defined interface,
• the cb can throw a defines exc,
• by adding a setIgnoredAttributes method

Please also squash your commits.

[tvlooy]

Yes, I like the setIgnoredAttributes solution. I changed it and squashed the commits.

[vicb]

I would throw an InvalidArgumentExcption in setCallbacks

[vicb]

php.net: InvalidArgumentException => "Exception thrown if an argument does not match with the expected value" is more accurate.

if a callback refers to an undefined function

not the case here

if some arguments are missing.

not the case here

[tvlooy]

yesyes, My bad. fixing it allready ;-)

[tvlooy]

changed it now. Thanks for your input

[tvlooy]

some improvements and squashed the commits

[stof]

@tvlooy Please rebase your branch. It conflicts with master because of the move of tests.

[tvlooy]

@stof I will do it on saturday, if that is ok with you.

[fabpot]

Is it mergeable now? ping @Seldaek, @schmittjoh.

[tvlooy]

yes, it should be