07.
Super Custom Serialization Fields
Keep on Learning!
If you liked what you've learned so far, dive in! Subscribe to get access to this tutorial plus video, code and script downloads.
If you liked what you've learned so far, dive in! Subscribe to get access to this tutorial plus video, code and script downloads.
Whoops, an error! Please, try again later.
11 Comments
Hi,
I have just a little question about the LinkSerializer, Imagine you want to add the other field 'uri' in the second entity.
Do you make an other subscriber or do you update the first one to handle the 2 cases?
In the case you decide to manage with the same, is it correct to add a second array in the getSubscribedEvent ?
thanks again for all your works
Cheers.
Hey Gregory!
If you want to do it via a "subscriber" it would be better to create another one, because our LinkSerializer is coupled to the Programmer entity, but you may end up with a lot of subscribers if you keep repeating this pattern, so you might want to go with the other approach that Ryan showed at the end of the video. Creating a model class which maps all the fields you want to return
Cheers!
Hi Diego,
Thanks for your answer, you're right it is an idea but Ryan shows us an other way in a future video.
Just need to remove the param "class" in the getSubscribedEvents
So next time, I'll waiting to finish all the videos before to ask ;)
Cheers
Awesome, let's keep learning!
Hi I have a problem with the eventsubscriber , it seems that it never get fired so when I am running the tests I get the following error:
`Symfony\Component\PropertyAccess\Exception\AccessException: Error reading property "uri" from available keys (nickname, avatarNumber, tagLine, powerLevel)`
Hey George!
Let's check if your eventsubscriber is working fine, put a dump with wathever value you want inside your method "onPostSerialize()" and lets see if it's printed when you hit the API, if not, there can be 2 things wrong:
1) Something in your service.yml file is wrong (probably the tag field), it should look like this:
2) The "getSubscribedEvents" method, it should look like this:
Have a nice day!
Just a comment, because I've found this to be REALLY helpful when I'm getting some specific data about my Entities, including aggregate values which cause mixed results. I've been creating Data Transformer Objects (DTO) that I can use within my DQL queries to populate that new DTO with the data. Like you said in the video, the separation helps me a lot in thinking of exactly what I'm exposing to the world.
Within that DTO, we can do all sorts of transformations with the data before serialization, including adding those extra fields like we do with the Serialization Event Subscribers or how you did within the controller.
Can see the documentation on this here:
http://doctrine-orm.readthe...
When my head gets all foggy from thinking about how to arrange those mixed results the way I want them, this helps in getting rid of that issue...
Also, cause I know you're reading this Ryan (because you're a shining example of not only the best teacher, but a fantastic businessman who cares about his customers!), if you have any cautions or comments on what I'm doing, I'd love your feedback!
I am trying to understand this method. It seems to me, and please correct me if I am wrong that this is a way to specify a database view (as in CREATE VIEW ... in SQL) using the Doctrine ORM. I have a situation where that is exactly what I need but I want to keep the data in contained classes (which I think of models of the entities) instead of doing a lot of work in the controller. This seems to be exactly what I am looking for. Thank you Jonathan.
Alberto, glad to help. Yes, I basically create models based off the entities when I'm using this "NEW" operator. It allows me to create a specific VIEW to use. If you have any questions or want to see any of my implementations of it, let me know!
I'd love to see your implementation of this. Let me know how you want to share it. Thank you!
Hi Jonathan!
That "new" operator in DQL is rad - how did I not know about this???!!! And ha, I have no cautions to give you - this looks really cool, and I can't agree more about "removing the foggy" by using these DTO's. Obviously, keep your queries organized in your repositories... but that's all I can say about this.
Thanks for sharing!
"Houston: no signs of life"
Start the conversation!