-
-
Notifications
You must be signed in to change notification settings - Fork 5.2k
Closed
Labels
SerializeractionableClear and specific issues ready for anyone to take them.Clear and specific issues ready for anyone to take them.
Description
The Serializer Component is being deeply reworked. It has gained some new features:
- Serialization groups: http://symfony.com/blog/new-in-symfony-2-7-serialization-groups
- Circular reference handling: [Serializer] Handle circular references symfony#12098
- Name Converters: [Serializer] Name converter support symfony#13120
I'm also working on making it a first class citizen of the framework (registered with the DIC and usable out of the box):
- [FrameworkBundle] Serializer groups support symfony#13107
- Serializer groups support symfony-standard#764
The next step will be to create a book entry (similar to the validation chapter) presenting basics and common uses of the Serializer with the full stack framework. We already started to discuss about that here: #4692 (comment)
What do you think about that? cc @wouterj @fabpot @Tobion @lsmith77 @Seldaek
Metadata
Metadata
Assignees
Labels
SerializeractionableClear and specific issues ready for anyone to take them.Clear and specific issues ready for anyone to take them.
Type
Projects
Milestone
Relationships
Development
Select code repository
Activity
fabpot commentedon Jan 16, 2015
👍 for a book entry. Serialization is an important topic in modern apps.
weaverryan commentedon May 22, 2015
@dunglas I just merged #4675, which is great, but the docs for the built-in serializer are really poor right now. As 2.7 is the first release where we (you) have finally made the serializer great, we should move quickly on the docs for it. Honestly, when I read the serializer docs we have so far, I'm confused about how to use it.
Here are some comments/questions I have - I am being a bit dumb, trying to get you my fresh impressions, which will probably be near what a new person will think:
I believe the
ObjectNormalizer
is not documented yet (other than being suddenly used in [Serializer] Doc for groups support #4675)In the components docs, we go back and forth between the
ObjectNormalizer
and theGetSetMethodNormalizer
. I don't really understand the difference. I believeObjectNormalizer
is the preferred, and if so, we should use it everywhere, and maybe just mention theGetSetMethodNormalizer
.The cookbook is terrible and uses the
GetSetMethodNormalizer
. Indeed, we need a proper chapter - I'm happy to help with this.Is the
setIgnoredAttributes()
only forGetSetMethodNormalizer
? Is there a way to ignore properties in theObjectNormalizer
, other than creating groups?It looks difficult to control the name of just one serialized property, since you need to introduce a whole "name converter". If I had a few properties across several classes that were "odd" and didn't follow the pattern, should I create just one "name converter" for my class and include these exceptions in there? Or should I have a separate "name converter" for each class (and thus a normalizer for each class)?
Thanks!
dunglas commentedon May 22, 2015
Hi,
The doc must be updated. It's on my todo list...
The two main thing to document IMO are:
It's because I've not changed the existing doc. To summarize:
It sounds good to me to just mention GetSetMethodNormalizer et PropertyNormalizer.
What about replacing the cookbook entry by a dedicated book entry (this issue)?
No, as for populating existing objects (another thing to document) and circular reference handling, I've moved this method it to
AbstractNormalizer
so it works with ObjectNormalizer, GetSetMethodNormalizer and PropertyNormalizer.IMO, using this method is not a good idea and I'm to promote the use of groups instead.
It's really up to you. I'll use only one "name converter" if there is only few case and split that converter if it start growing.
weaverryan commentedon May 23, 2015
@dunglas agree on all points, and thanks for the clarifications! Any help you can offer to get the docs going is much appreciated. My worry would be that we all get busy and it doesn't get updated, which for most users would mean that the component is still unusable, and that would be a shame :). I will do my best, but I'm spread too thin to be dependable.
Agree on adding a book article. But my current philosophy is that the book should show the main use-cases. Anything that's more advanced or edge-case can be added to a cookbook. I hear often that people love the "How do I do X" articles in the cookbook, because it's so easy to find answers to questions when they're not hidden in the middle of a giant book article.
I agree on pushing groups instead of
setIgnoredAttributes()
, especially since that is set on the normalizer... which makes it seem to me that you'd need a normalizer for every object (is that correct?). Anyways, I think keeping the serializer metadata in one post (annotations, XML, whatever) is a big reason people like JMS, and using Groups only follows this.I like the "name converter" idea, but I also do like the
@SerializedName
ability from JMS. So, maybe consider that a small vote for that feature from me ;).Thanks @dunglas!
feature #5332 [Serializer] ObjectNormalizer, object_to_populate doc. …
GuilhemN commentedon Mar 31, 2016
I guess this is still actual, I tried to find a documentation describing how to create custom normalizers (to add it to the FOSRestBundle doc) but I didn't find.
If you want I can try to submit a pr but I didn't write many docs so I don't know how the result will be.
wouterj commentedon Apr 2, 2016
@Ener-Getick such an article perfectly fits the components section, we don't need a book article for that. The good news is that you can start writing that article now :)
And don't worry about your doc-writing capabilities, we'll help you to create a nice article. If you're unsure about anything, don't hesitate to ask for help in a comment on GitHub or via the #symfony-docs channel on IRC.
7 remaining items