[Serializer] Name converter support #13120

dunglas · 2014-12-25T23:55:40Z

Q	A
Bug fix?	no
New feature?	yes
BC breaks?	no
Deprecations?	yes
Tests pass?	yes
Fixed tickets	#12212
License	MIT
Doc PR	symfony/symfony-docs#4692

This PR adds support for custom property naming strategies to the serializer and provides a built-in NameConverter using this new system: (CamelCase to underscore).
It handles normalization and denormalization (convert fooBar to foo_bar when serializing, then from foo_bar to fooBar when deserializing). It also has a flag to convert only some attributes.

The setCamelizedAttributes() is deprecated in favor of this new method (more flexible, allows to rename all attributes of a class and support deserialization) and now uses it internally.

hhamon · 2014-12-26T10:01:12Z

src/Symfony/Component/Serializer/Normalizer/AbstractNormalizer.php

     */
-    public function __construct(ClassMetadataFactory $classMetadataFactory = null)
-    {
+    public function __construct(


The constructor signature should be a one liner I guess?

This line will be longer than 80 characters.

I know but as far as I know we don't wrap lines that exceeds 80 characters (even 120 characters).

Ok changed.

Tobion · 2014-12-26T14:53:57Z

What is the intention with the serializer component? I think we should not just blindly rebuild all the features that the JMS serializer already has. IMO both serializers should join forces and make one good one that is also faster than the current JMS serializer. There is no point in just reinventing the wheel here.

dunglas · 2014-12-27T22:17:28Z

Hi @Tobion,

My intention is not to blindly copy/reinvent JMS Serializer. I’ve already explained the need here: #12092 (comment)

To summarize, I think we need:

a fully featured MIT (so GPLv2 compliant) serializer (this is not the case of JMSSerializer)
to be able to develop powerful REST (and non-REST) APIs only with Symfony, without finding and installing a ton of external dependencies
something really extensible and high performance

The Symfony Serializer Compnent already has something similar to this feature (it’s why I deprecated it) but it has several drawbacks:

it handles only underscore -> CamelCase but is not flexible enough to handle other cases
it’s not symmetrical: it converts when deserializing but not when serializing
it’s not convenient to use: you must specify the full list of properties you want to convert but you cannot say « convert all properties » (see the ticket linked in the PR).

In fact, the Serializer Component will be lighter and more efficient by default with the Name Converter System than with the current implementation because it will not be enabled/registered without manual setting (so not loaded in memory).

I think converting property names when serializing is a basic feature wanted by many people using a serializer. I've added a doc explaining some of these very common use cases: https://github.com/symfony/symfony-docs/pull/4692/files?diff=split

Naming Strategies of JMSSerializer are similar but not as powerful. AFAIK the JMS implementation as the inverse drawback than the current Serializer Component implementation: it can rename attributes while serializing but not when deserializing.

They are a lot of features I don’t want to see in the Serializer Component because they are redundant or will decrease its speed including:

Different ways to pick attributes to serialize (@Exclude, @Expose and so on): groups are sufficient and only one way to do seems to me better design and easier to use and understand
API versioning: can be handled and is similar to serialization groups
Annotations (or XML/YAML) for everything such as serialization names: a custom Name Converter is sufficient for such special needs
Event system (do we really need events for something like serialization?)

However, JMSSerializer is a very powerful and well thinked library. I think we can study how it works and the experience with it to build something lighter but as powerful.
We cannot share code between the two projects because of the licensing issue but we can share good ideas and design.
When reimplementing concepts existing in other libraries such as JMSSerializer or the Django Serializer, I try to go one step further without bloating the code. Check for instance the depth and callback system for the circular reference handler and the symmetry support in this one.

One other thing I would like to see in the Symfony component is a more generic way than the callbacks system to handle special serialization (e.g.: being able to do something when encountering a special type like \DateTime).

Tobion · 2014-12-28T03:25:50Z

Thanks for the explanation. I agree having a more lightweight, MIT serializer that covers the JMS use-cases would be good.

AFAIK the JMS implementation as the inverse drawback than the current Serializer Component implementation: it can rename attributes while serializing but not when deserializing.

No, it works both ways.

dunglas · 2015-01-04T20:59:31Z

Should be merged only after #13252 (and will need a rebase).

fabpot · 2015-01-07T12:47:31Z

@dunglas #13252 is merged now, can you rebase?

dunglas · 2015-01-09T09:25:05Z

@fabpot rebased.

fabpot · 2015-01-09T14:05:02Z

src/Symfony/Component/Serializer/Normalizer/AbstractNormalizer.php

-     * @param string $attributeName
-     * @return string
-     */
-    protected function formatAttribute($attributeName)


That's a BC break.

dunglas · 2015-01-11T21:23:32Z

@fabpot BC break reverted.

xabbuh · 2015-01-12T14:08:04Z

src/Symfony/Component/Serializer/Normalizer/AbstractNormalizer.php

-                return ('.' === $match[1] ? '_' : '').strtoupper($match[2]);
-            }, $attributeName);
-        }
+        trigger_error('The formatAttribute() method has been deprecated. Use Symfony\Component\Serializer\NameConverter\CamelCaseToSnakeCaseNameConverter instead.', E_USER_DEPRECATED);


Using __METHOD__ would be better than using formatAttribute() (otherwise you don't know the method's class).

and the wording actually is a bit different: http://symfony.com/doc/current/contributing/code/conventions.html#deprecations

dunglas · 2015-01-12T15:29:30Z

@xabbuh fixed

xabbuh · 2015-01-12T15:37:42Z

@dunglas You should use the actual version numbers instead of 2.X and 2.Y. ;)

dunglas · 2015-01-12T15:39:13Z

Oops :)

dunglas · 2015-01-12T15:40:46Z

fixed

fabpot · 2015-01-16T07:32:54Z

👍

stof · 2015-01-18T17:21:03Z

src/Symfony/Component/Serializer/Normalizer/AbstractNormalizer.php

+            }, $camelizedAttribute));
+        }
+
+        $this->nameConverter = new CamelCaseToSnakeCaseNameConverter($attributes);


this will break if a NameConverter was passed in the constructor (you will removed the existing one entirely)

This is intended.
As NameConverter deprecate this method, both must not be used together. I'll add the throwing of an exception in that case (I thought it was done, but this is not the case).

Exception added.

stof · 2015-01-18T17:22:26Z

Please rebase this to fix conflicts (the logic common to the GetSetNormalizer and the PropertyNormalizer has been moved to their common parent class)

dunglas · 2015-01-18T20:52:40Z

Rebased. Thanks @stof for the review.

dunglas · 2015-01-23T10:02:21Z

Tests fixed.

fabpot · 2015-01-25T03:47:06Z

@dunglas Looks like the tests are not fixed (at least, according to Travis)

dunglas · 2015-01-25T20:10:37Z

@fabpot strange Travis issue. Commits squashed, now Travis has detected the changes.

fabpot · 2015-01-26T16:07:03Z

@dunglas Tests pass now on Travis as well apparently.

stof · 2015-01-30T03:59:16Z

The changelog of the component should be updated to mention the changes being done (adding the new feature and deprecating the old one). Otherwise 👍

dunglas · 2015-02-02T22:13:24Z

Updated the changelog with new features of 2.6. I've also added a new feature of 2.6 missing from the changelog. Should I create a separate PR on the 2.6 branch for that?

fabpot · 2015-02-03T06:45:53Z

src/Symfony/Component/Serializer/CHANGELOG.md

 2.6.0
 -----

 * added a new serializer: `PropertyNormalizer`. Like `GetSetMethodNormalizer`,
   this normalizer will map an object's properties to an array.
+ * added circular references handling for `GetSetMethodNormalizer`


Indeed, you should submit a PR on 2.6 for this one.

fabpot · 2015-02-03T06:47:38Z

Thank you @dunglas.

This PR was merged into the 2.7 branch. Discussion ---------- [Serializer] Name converter support | Q | A | ------------- | --- | Bug fix? | no | New feature? | yes | BC breaks? | no | Deprecations? | yes | Tests pass? | yes | Fixed tickets | #12212 | License | MIT | Doc PR | symfony/symfony-docs#4692 This PR adds support for custom property naming strategies to the serializer and provides a built-in NameConverter using this new system: (CamelCase to underscore). It handles normalization and denormalization (convert `fooBar` to `foo_bar` when serializing, then from `foo_bar` to `fooBar` when deserializing). It also has a flag to convert only some attributes. The `setCamelizedAttributes()` is deprecated in favor of this new method (more flexible, allows to rename all attributes of a class and support deserialization) and now uses it internally. Commits ------- 86b84a5 [Serializer] Update changelog e14854f [Serializer] Name converter support

This PR was merged into the 2.7 branch. Discussion ---------- [Serializer] ObjectNormalizer | Q | A | ------------- | --- | Bug fix? | no | New feature? | yes | BC breaks? | no | Deprecations? | no | Tests pass? | yes | License | MIT | Doc PR | not yet `PropertyAccessNormalizer` is a new normalizer leveraging the PropertyAccess Component. It is able to handle classes containing both public properties and properties only accessibles trough getters / setters / issers / hassers... As it extends `AbstractNormalizer`, it supports circular reference handling, name converters and existing object population. What do you think about making this new normalizer the default one as it's the most convenient to use and the most consistent with the behavior of other components. #13120, #13252 and #13255 need to be merged to make this PR working. Commits ------- 0050bbb [Serializer] Introduce ObjectNormalizer

This PR was merged into the 2.7 branch. Discussion ---------- [Serializer] Name Converter | Q | A | --------------- | --- | Doc fix? | no | New docs? | yes symfony/symfony#13120 | Applies to | 2.7 This is the documentation for the Serializer Name Converter feature. Commits ------- d335005 [Serializer] Fix CS 0442752 [Serializer] Acme things 57e6c94 [Serializer] Name Converter fixes 24d0320 [Serializer] Use firtName and snake_case 4ecc706 [Serializer] Name Converter corrections. b59b752 [Serializer] Name Converter

hhamon reviewed Dec 26, 2014
View reviewed changes

dunglas force-pushed the name_converter branch from dc3e274 to 7b9bb36 Compare December 26, 2014 10:26

dunglas mentioned this pull request Dec 27, 2014

[Serializer] Name Converter symfony/symfony-docs#4692

Merged

dunglas mentioned this pull request Dec 28, 2014

Add a book entry for serialization symfony/symfony-docs#4698

Closed

fabpot added the Serializer label Jan 2, 2015

dunglas mentioned this pull request Jan 4, 2015

[Serializer] ObjectNormalizer #13257

Merged

fabpot force-pushed the 2.7 branch from 77b6cca to dcfc338 Compare January 8, 2015 13:06

dunglas force-pushed the name_converter branch 4 times, most recently from 00f5efb to e4f34a7 Compare January 9, 2015 09:23

fabpot reviewed Jan 9, 2015
View reviewed changes

dunglas force-pushed the name_converter branch from e3f3980 to fb65100 Compare January 11, 2015 21:21

xabbuh reviewed Jan 12, 2015
View reviewed changes

dunglas force-pushed the name_converter branch from 7e40c6d to 80191a3 Compare January 12, 2015 15:40

stof reviewed Jan 18, 2015
View reviewed changes

dunglas force-pushed the name_converter branch from 80191a3 to e7b1e86 Compare January 18, 2015 20:52

dunglas force-pushed the name_converter branch from e7b1e86 to 2cbd4ea Compare January 23, 2015 10:02

[Serializer] Name converter support

e14854f

dunglas force-pushed the name_converter branch from 2cbd4ea to e14854f Compare January 25, 2015 19:53

[Serializer] Update changelog

86b84a5

fabpot reviewed Feb 3, 2015
View reviewed changes

fabpot merged commit 86b84a5 into symfony:2.7 Feb 3, 2015

dunglas deleted the name_converter branch December 5, 2015 09:01

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[Serializer] Name converter support #13120

[Serializer] Name converter support #13120

dunglas commented Dec 25, 2014

hhamon Dec 26, 2014

dunglas Dec 26, 2014

hhamon Dec 26, 2014

dunglas Dec 26, 2014

Tobion commented Dec 26, 2014

dunglas commented Dec 27, 2014

Tobion commented Dec 28, 2014

dunglas commented Jan 4, 2015

fabpot commented Jan 7, 2015

dunglas commented Jan 9, 2015

fabpot Jan 9, 2015

dunglas commented Jan 11, 2015

xabbuh Jan 12, 2015

xabbuh Jan 12, 2015

dunglas commented Jan 12, 2015

xabbuh commented Jan 12, 2015

dunglas commented Jan 12, 2015

dunglas commented Jan 12, 2015

fabpot commented Jan 16, 2015

stof Jan 18, 2015

dunglas Jan 18, 2015

dunglas Jan 18, 2015

stof commented Jan 18, 2015

dunglas commented Jan 18, 2015

dunglas commented Jan 23, 2015

fabpot commented Jan 25, 2015

dunglas commented Jan 25, 2015

fabpot commented Jan 26, 2015

stof commented Jan 30, 2015

dunglas commented Feb 2, 2015

fabpot Feb 3, 2015

fabpot commented Feb 3, 2015

[Serializer] Name converter support #13120

[Serializer] Name converter support #13120

Conversation

dunglas commented Dec 25, 2014

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Tobion commented Dec 26, 2014

dunglas commented Dec 27, 2014

Tobion commented Dec 28, 2014

dunglas commented Jan 4, 2015

fabpot commented Jan 7, 2015

dunglas commented Jan 9, 2015

Choose a reason for hiding this comment

dunglas commented Jan 11, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dunglas commented Jan 12, 2015

xabbuh commented Jan 12, 2015

dunglas commented Jan 12, 2015

dunglas commented Jan 12, 2015

fabpot commented Jan 16, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

stof commented Jan 18, 2015

dunglas commented Jan 18, 2015

dunglas commented Jan 23, 2015

fabpot commented Jan 25, 2015

dunglas commented Jan 25, 2015

fabpot commented Jan 26, 2015

stof commented Jan 30, 2015

dunglas commented Feb 2, 2015

Choose a reason for hiding this comment

fabpot commented Feb 3, 2015