Add default SerializerContext to serializer, update builder

[alcalyn]

This PR adds a default SerializerContext factory and SerializerContext factory in Serializer class to avoid to pass a context every time we call serialize, deserialize, toArray or fromArray.

It also update the serializer builder by adding setDefaultSerializerContextFactory and setDefaultDeserializerContextFactory methods, allowing to pass a callable which create a context.

Now we can set a default serializer context factory by doing this:

use JMS\Serializer\SerializationContext;

$serializer = \JMS\Serializer\SerializerBuilder::create()
    ->setDefaultSerializationContextFactory(function () {
        return SerializationContext::create()
            ->setSerializeNull(false)
        ;
    })
    ->build()
;

[alcalyn]

For now I made it as simple as possible by using php Closure, then we can use the builder like that:

$serializer = \JMS\Serializer\SerializerBuilder::create()
    ->setDefaultSerializationContextFactory(function () {
        return \JMS\Serializer\SerializationContext::create()
            ->setSerializeNull(true)
        ;
    })
    ->build()
;

[nuxwin]

@alcalyn

Please, don't enforce closure for the factory. Eg, in zf2 service manager, it is recommended to use factory classes which is much better. You could maybe enforce callable. This would allow invokables.

[alcalyn]

Yep I started to create interfaces SerializationContextFactoryInterface and DeserializationContextFactoryInterface, but I find it too verbose at first

[nuxwin]

At first... Don't worry about verbosity. It is much better to rely on interface ;)

Thanks for your work anyway. I need this.

[alcalyn]

Now we can set a default serializer context factory by doing this:

use JMS\Serializer\ContextFactory\SerializationContextFactoryInterface;
use JMS\Serializer\SerializationContext;

class MySerializationContextFactory implements SerializationContextFactoryInterface
{
    public function createSerializationContext()
    {
        return SerializationContext::create()
            ->setSerializeNull(true)
        ;
    }
}

Then:

$serializer = \JMS\Serializer\SerializerBuilder::create()
    ->setDefaultSerializationContextFactory(new MySerializationContextFactory())
    ->build()
;

[alcalyn]

Last commit allows to use a callable in Serializer builder for a shorter syntax. Example:

$serializer = \JMS\Serializer\SerializerBuilder::create()
    ->setDefaultSerializationContextFactory(function () {
        return SerializationContext::create()
            ->setSerializeNull(false)
        ;
    })
    ->build()
;

[alcalyn]

What about this PR ? @schmittjoh

[goetas]

To me looks a bit too much 500 lines of code, just to have a default implementation of the context... that anyway changes for each usecase

[alcalyn]

Mmh in theses 500 lines, its about 200 lines for testing, 120 for license, a bunch of one-method interfaces...

And I just needed it this morning because I don't want to create a wrapper around serializer service to only create a new context with setSerializeNull(true) on each serialize.

Maybe another solution is to set serializeNull in config instead of context, but also setGroups and enableMaxDepthChecks could be in config, because as a new user, I don't know why a part of configuration is in builder, and another part in context...

So that's why I think a default context factory in builder is not déconnant :D

[nuxwin]

@goetas

For our project, we have interest too in that PR. Please, merge it ;)

@alcalyn ---> Déconnant ???

[alcalyn]

is not irrevelant* :P

[goetas]

Personally I can agree with having a context factories, but what is the use case for the callable context factories?

They are already part of a specific implementation, so probably they should stay in your project, while the default factories should stay here... is it?

[alcalyn]

the callable context factory is to avoid to create a class which just call setSerializeNull(true), and provides a more "builder" way to add a default context (see #541 (comment)).

[goetas]

What do you think about renaming some variables as in #645 ?

(i have just removed the "default" prefix that was looking redundant to me)

[alcalyn]

Okey, its shorter

[alcalyn]

I close it in favor to #645