I am against both merging and putting JMS Serializer into core (@hhamon and @couac). In my opinion it has its use-cases, but should be also used with care, because of some limitations and assumptions that may be too much for standard distribution:
1. Updating of graphs not possible, just creating new ones. That requires merging manually, which is quite complex for medium sized object graphs. 2. One representation per object only. There are "groups", but they are severly limited as they don't allow different types per property per group for example. This means its very tedious to have two representations of the same object (one small for lists, one big graph for details for example). Also its tricky to get things working with bidrectional associations without rendering the whole database. 3. Arrays to XML require lots of boilerplate struct classes to be written. 4. Traversable is handled as array, making those boilerplate classes from 3. unusable as domain specific collections for example. Regarding 1, we have the form component for that, and i have shown in https://github.com/simplethings/SimpleThingsFormSerializerBundle that its quite easy to combine Symfony Serializer and Form to update an existing object graph from XML or JSON. The only problem here is that updating a graph using form component is much slower performance wise than creating a new one with JMS. So this depends on your application what your requirements are. Regarding 2, this is not a problem for CRUD apps with no peformance requirements, but as soon as you want more complex serialization views, lists and detail views, this gets quite problematic. The Serializer component is very powerful already, imho it only needs the possibility for additional configuration per call to serialize/normalize/encode etc. With that it would be easy to implement a generic Doctrine Normalizer that works like http://api.rubyonrails.org/classes/ActiveRecord/Serialization.html and this would also allow JMS Serializer to implement the SerializerInterface. On Fri, Aug 24, 2012 at 11:42 AM, Lukas Kahwe Smith <[email protected]>wrote: > > On Aug 24, 2012, at 11:06, Christophe COEVOET wrote: > > > Le 24/08/2012 10:57, William Durand a écrit : > >> Johannes wrote this bundle as well as many components in the core. I > don't see any problems with that. The Filesystem and the Routing components > have been improved by people who are not part of the core team. > >> > >> William > >> > >> PS: I still don't get who is part of the core team, who is not, why and > why not? :) > >> > > Well, the issue is that if it goes in the core, it has to be maintained > by Fabien: all changes in the core go through him, even when being done by > Johannes. So keeping it as a separate bundle makes the maintenance easier > (and also allows to have a separate release cycle for the bundle). > > note that it is also the reason why MonologBundle and SwiftmailerBundle > are not in the core in 2.1 anymore (and why AsseticBundle was extracted > before the 2.0 release). > > > Well the Bundle should stay separate .. if at all the "serializer" part of > the Bundle should be moved. If it doesnt get moved imho it would be great > to at least separate it from the Bundle either way. Of course Johannes has > no small say in all of this :) > > regards, > Lukas Kahwe Smith > [email protected] > > > > -- > If you want to report a vulnerability issue on symfony, please send it to > security at symfony-project.com > > You received this message because you are subscribed to the Google > Groups "symfony developers" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/symfony-devs?hl=en > -- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.com You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en
