It is not light anymore. It resembles much more to the way Zend does things. Zend comes with Services for almost everything Amazon/Audioscrobbler/Akismet you name it. And this seems the route we are taking now but adding classes for optional integration into the components or a seperate component namespace and at some point it will be a monster to get down and use.
The lightness in Symfony2 to me was that the Core only contained classes / helpers etc that was needed and the rest was optional extensions that can be found in other ways or by other people just like Doctrine2 does with not having any Extensions bundled with them. Would you really like Doctrine2 to have Sortable,NestedSet,Timestampable etc be bundle inside it as Doctrine1? If i remember correctly one of the biggest to use Symfony1 was Yahoo and they did not use Doctrine / Propel but their sites were purely API driven. Why should they then have component extensions lying around with functionality they will never need? Its wasted space. What will happen when Doctrine releases 2.1 and something breaks in the Component extensions. You would better be very fast (on the same day) to update the components so they are always up to date. Can you, Bernhard, Johannes promise to do that? for every release? forever? if so then you guys have much more freetime than most. This also removes the need for bundles to follow the PSR-0 naming standard. They could just aswell alway have been in Bundle\VendorName\MyBundleName and still be named the same way as today. What is the reason to have them follow that naming conventions if they are forever only to be used inside the framework? Lets take MenuBundle as an example. With this the best practice would be to have libraries as generic as possible and then have a Bundle for them to be integrated into Symfony2 by only a Bundle class, a DepencencyInjection Extension, and a Config file for that extension. That means that MenuBundle\Menu and MenuBundle\MenuItem would have to be in their own library. This also means that to install it you would have to add a new library and a bundle which must be regitered twice (if the fallback is not used). Which will make installing third party bundles wich will and already does contain simple logic that have relevance outside Symfony2. For Security i certainly see that there are some reason that DBAL is easier to work with than PDO. But why not provide a integration with PDO and remove the need to have a dependency in that component altogether? We could still have a DBAL integration in DoctrineBundle that uses its configured dbal.connection (as it is the way today). This certainly makes me reconside my start of using Symfony2. If i wanted all this i could just go use Zend Framework. -- 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
