To me this discussion is as bike shedding as the one we had with changing the component namespaces. There is no right or wrong here, both have advantages, and both have their drawbacks.
Right now, we group classes by their purpose; with your proposal we would group them by the vendor they are for. The first has the advantage that the installation is very easy, all security code is in one place, all form code is in one place, all validator code is in one place. The latter requires a more complex installation procedure, and the user doesn't have all the code related to the component in one place, but scattered over various folders which makes it harder to find things. Also as I said when we discussed it on Saturday, I don't think that we can press everything into the same pattern. You say that Security/Acl is special, I could argue that Twig is special, probably both are special in their own ways. Why do we need to integrate them in the same way then? Just to give you one example, Security/Acl without Doctrine makes no sense, it doesn't work, the component would become unusable. The YAML component without Twig still works, it can parse YAML files. So, while I share your sentiment that having Twig related files in the YAML component feels wrong, I don't see that your proposal makes sense for Security/Acl. So, while it solves one problem it creates another. That's why I think that we need a more differentiated approach to this problem, we cannot press everything into the same pattern, things are very different... IMO, if we go ahead with your proposal, exceptions must be allowed where they make sense. Some examples for such exceptions: Form\FieldFactory\EntityFieldFactoryGuesser Form\EntityChoiceField Routing\Loader\AnnotationClassLoader Security\Acl Security\Core\User\EntityUserProvider Validator\Mapping\Loader\AnnotationLoader Kind regards, Johannes On Mon, Feb 28, 2011 at 8:29 AM, Fabien Potencier < [email protected]> 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 > -- 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
