It all sounds pretty reasonable to me. +1 On Feb 28, 8:29 am, Fabien Potencier <fabien.potenc...@symfony- project.com> wrote: > A few weeks ago, we had a discussion about where to put the integration > between the Symfony Components and third-party libraries. > > To refresh your memories, let's say that Symfony Components are > re-usable and *standalone* libraries that can be used without the > Symfony full-stack framework. They *must* not have any mandatory > externals dependencies (they can however have mandatory dependencies on > other Symfony2 components -- like Form and Validator for instance). > > At the time of the decision, we had two main examples: the use of > Doctrine for the Security Component (for the ACLs -- which is a lot of > code), and one class in Form Component for Doctrine support. We decided > to put the glue code in the components themselves mainly because of the > ACL support. The main argument was that without the ACL implementation > within the component, the ACL part of the Security component was not > really useful (as it would have been a bunch of interfaces). So, we > decided to do the same for the Form framework to be consistent. > > So, what has changed since then and why I think we need to take another > direction now? > > Last week, I wanted to use the Translation Component outside of a > Symfony project, and this project happens to also use Twig. So, I needed > to integrate Twig and the Translation Component together and soon, I > realized that this integration already exists in TwigBundle. I could > have used the Twig bundle as is without using the Symfony framework as > this is just another namespace, but it just feels weird. So, at first, I > asked Simon at Sensio to move classes from the Twig bundle to the Twig > Extensions repository (in a new TwigX namespace). > > Then, on Saturday, during a Sensio hackaton, we started to discuss this > matter again. First TwigX is not really a vendor name, and then, we > realized that the problem is really similar that the one we have with > the Symfony Components and Doctrine integration. And of course, we > cannot decide to create a DoctrineX namespace. > > Where to put this glue code then? We have these possibilities: > > * In the Bundles: even if is technically possible, this is out of > question as it feels weird for a user not using the framework to ask him > to install Symfony bundles. > > * In the third-party libraries (in Twig, Doctrine): this is not really > possible as each library should only be about its own code and not about > the integration of third-party code. > > * In the Components: that's the decision we made. But now that we have > many more examples, I think this is not the right decision anymore (also > because of the git sub-tree thingy -- more on that below). For example, > having the 'yaml_encode' Twig filter under the Yaml Component feels > really bad. > > * In a new Symfony sub-namespace: that's my proposal today. > > The new Symfony sub-namespace goal is to host the glue code between the > Symfony Components and third-party libraries. This idea was not really > considered when we discussed this topic last time because it was really > about two use cases and one of them (the Security/Doctrine integration) > was really specific as explained above. > > The more we thought about this, the more we thought it was the way to > go, also because moving classes away from the Twig bundle gave us many > more examples: > > * Yaml Component: the 'yaml_encode' Twig filter; > * Router Component: the 'path' and 'url' Twig functions; > * Templating Component: the 'asset' function. > * Form Component: all the form related functions and tags; > > Adding a new namespace makes a lot of sense now that we have many more > examples. It also makes a lot of sense as one of our mantra is to not > reinvent the wheel. So, if we want others to also adhere to our > principles, we need to make it really easy to integrate the Symfony > wheel within their own projects. > > So, along the Symfony\Component and Symfony\Bundle namespaces, I propose > to add a Symfony\Bridge namespace: > > Symfony\Bridge\Twig\Extension\TransExtension > Symfony\Bridge\Twig\Extension\FormExtension > Symfony\Bridge\Twig\Extension\YamlExtension > Symfony\Bridge\Doctrine\ACL\ > Symfony\Bridge\Doctrine\Form\ > ... > > What does it mean for the developer? > > For the "average" Symfony Framework user: This change is totally > transparent as the Symfony\Bridge namespace will be hosted under the > main Symfony repository. > > For the developer who just want to use some of our components: If he > wants to use a standalone component, it changes nothing; if he wants to > use a component with a third-party library that we support, then he can > just get the related bridge. And this is really easy now that we have > the Git sub-trees. Like we have one Git repository per component > (read-only), we will also have one repository per bridge. So, working > with Doctrine and the Form Component for instance means that you need to > get the Doctrine repos, and two small dependencies: > > * The Form component repo: symfony/Form > * The Doctrine bridge repo: symfony/DoctrineBridge > > As you can see, instead of managing two repositories, the developer will > now have to manage three of them, not a big deal. And it seems like > things will then be explicit (you need to explicitly get the bridge if > you need it), more decoupled (the components do not have optional > dependencies anymore), and easier to understand (you know where to look > for things). > > I realize that we make a discussion a few weeks ago, but I think that we > now have many more examples that demonstrate this decision we took is > not the best one anymore. And last but not the least, it addresses the > concerns some of you had when we decided to put everything in the > components. > > Fabien > > -- > Fabien Potencier > Sensio CEO - Symfony lead developer > sensiolabs.com | symfony-project.org | fabien.potencier.org > Tél: +33 1 40 99 80 80
-- 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
