[Serializer] Added a ChainEncoder and a ChainDecoder

These classes contains the logic previously defined in the Serializer
itself to handle the choice of a serializer. This allows reusing it when
using only the encoding part of the component.
Moved the NormalizationAwareInterface check to the ChainEncoder

This allows nesting a ChainEncoder inside another one without breaking
the check.
Fixed: The type name specified for the service propel.form.type.model does not match the actual name 
merged branch cvschaefer/master (PR #4920)

Commits
-------

a80ef6b Fixed: The type name specified for the service propel.form.type.model does not match the actual name

Discussion
----------

[Propel1Bridge][Form] ModelType name is invalid

Since 6489a65960a05b6a5a4f5c5074b941a6765c6381 "[Form] Added an exception for invalid type services" Symfony/Component/Form/Extension/DependencyInjection/DependencyInjectionExtension requires form type names to match the service name.

This fixes exception "The type name specified for the service propel.form.type.model does not match the actual name"

---------------------------------------------------------------------------

by willdurand at 2012-07-14T14:03:20Z

:+1:

---------------------------------------------------------------------------

by fabpot at 2012-07-14T14:17:36Z

I think it would be better to named it `propel_model`.

---------------------------------------------------------------------------

by willdurand at 2012-07-14T14:20:05Z

There is `entity` for Doctrine entities, not `doctrine_entity`. This should
be the same for Propel...

2012/7/14 Fabien Potencier <
reply@reply.github.com
>

> I think it would be better to named it `propel_model`.
>
> ---
> Reply to this email directly or view it on GitHub:
> https://github.com/symfony/symfony/pull/4920#issuecomment-6983217
>

---------------------------------------------------------------------------

by stloyd at 2012-07-14T14:22:34Z

@fabpot @willdurand Or we should rename Doctrine one too, to be more consistent...

---------------------------------------------------------------------------

by fabpot at 2012-07-14T14:30:41Z

We should definitely rename Doctrine too.

---------------------------------------------------------------------------

by cvschaefer at 2012-07-14T14:34:51Z

@fabpot Wouldn't that break all existing forms with doctrine entity form types?

---------------------------------------------------------------------------

by stof at 2012-07-14T14:54:03Z

It would break BC indeed, and changing the propel type name in the DIC config (which is the one used in before the latest refactoring) would also be a BC break.

And btw, we also use ``entity`` in the SecurityBundle config, not ``doctrine_entity``

---------------------------------------------------------------------------

by fabpot at 2012-07-14T15:04:31Z

You're right, let's not break BC for the sake of it.

---------------------------------------------------------------------------

by stof at 2012-07-14T15:13:23Z

Ok, so this PR should be merged as is, as I guess more people are using the Propel type in a PropelBundle context than with a standalone Form component (which would have used the getName method)

---------------------------------------------------------------------------

by cvschaefer at 2012-07-14T15:14:44Z

+1
merged branch excelwebzone/validator (PR #4924)

Commits
-------

ddbb26e [Validator] updated hebrew messages

Discussion
----------

[Validator] updated hebrew messages
merged branch stof/serializer_improvement (PR #4904)

Commits
-------

12bdec3 Moved the NormalizationAwareInterface check to the ChainEncoder
28e137c [Serializer] Added a ChainEncoder and a ChainDecoder

Discussion
----------

[Serializer] Added a ChainEncoder and a ChainDecoder

Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: [![Build Status](https://secure.travis-ci.org/stof/symfony.png?branch=serializer_improvement)](http://travis-ci.org/stof/symfony)
Fixes the following tickets: -
Todo: -

These classes contains the logic previously defined in the Serializer itself to handle the choice of a serializer. This allows reusing it when using only the encoding part of the component, without having to use the Serializer class (which is not as handy to bootstrap when you want to use only encoders and decoders as normalizers come first)

I was wondering if these classes should have adders but I kept the constructor injection only to be consistent with the current code (encoders cannot be registered after the instantiation) and to avoid implementing the SerializerAwareInterface in them (to allow injecting the Serializer in serializer-aware encoders and decoders added later).

Note that this change is fully BC as it only changes the internal implementation of the Serializer.

---------------------------------------------------------------------------

by fabpot at 2012-07-14T11:07:32Z

ping @lsmith77 @Seldaek

---------------------------------------------------------------------------

by Seldaek at 2012-07-14T15:17:42Z

After a quick look, I'd say +1
[Validator] more updated hebrew messages