On Fri, Jan 28, 2011 at 2:08 PM, Benjamin Eberlei <[email protected]>wrote:
> Well all in all there is exactly one argument that henrik and I have kept > repeating and rephrasing: > > Ship the Doctrine code in the Doctrine bundle, because there it belongs. > It is for the same reasons that there is a Twig Bundle, a Zend Bundle and a > Swiftmailer bundle. All of these 3 componentes have exactly zero code in > the Symfony\Component namespace. I fail to see how we can argue that we > support Doctrine, Twig and Swiftmailer, however still keep the code of Twig > and Swiftmailer in their bundles, and moving Doctrine code to > Symfony\Component. > I find this argument pretty weak. Just because it is the practice right now, it doesn't mean that it has to stay this way, and in our opinion there are overwhelming reasons not to continue with this practice. > > There are several small examples (glitches in the DIC matrix) were it is > visible that DBAL/Doctrine code in the components lead to weird depenedncy > problems: > > # app/config/security.yml > security.acl: > connection: default > > Security Extension is defined in the Framework bundle but it knows > something about "connections". What is that even for a concept for the > Security bundle to know? Clearly the dependencies should be the other way > around leaving you to define a service that handles the acl: > > # app/config/security.yml > security.acl: > service: my.dbal.service > > In this case the service would be defined by the DoctrineBundle where it > properly belongs. However then the code wouldnt be shipped in the > DoctrineBundle and lie somewhere different. So the security acl extension > is just build to support Doctrine as a special case to make it look as if > the dependencies were defined in a straightfoward way. > > Other code defines in the orm.xml the entity classes and repositories that > are used for the Default Security Provider > "Symfony\Bundle\DoctrineBundle\Security\EntityUserProvider": > > > https://github.com/fabpot/symfony/blob/master/src/Symfony/Bundle/DoctrineBundle/Resources/config/orm.xml#L41 > > However the service itsself is again defined in the Security Extension. > Clearly a breakage of concerns. So if you went over and pulled all the > stuff into the Security extension but you don't enable the Doctrine Bundle, > everything breaks. So yes, you have a dependency from Framework/Security on > DBAL. > This is debatable, and there is no right or wrong. I don't see why we should argue all over that again, we could do so endlessly. The only hard fact that remains is that the component itself is not usable if we do that, and this outweights the more philosophical approach you're taking here. However, as we have stated, there must not be a required dependency on Doctrine. The current state of things, again, is not consistent and will need to be cleaned up. > I havent looked at the form Doctrine dependencies yet, but i will sure > find similar "weird" constructs in the Extension there. > > Our strict application of Dependency Injenction and the failure to comply > with it package wise leads to this "glitches" in the matrix that show the > dependencies are wrong, A depends on B where it should be the other way > around. Form and Security should only provide extension hooks to the > outside world and Doctrine is one "provider" that can hook into them. If > Doctrine were to hook into it, configuration would surely be in the > Doctrine Extension. Which would look rather weird if the code is not itself > in the DoctrineBundle. > The Symfony2 end-user/developer is by no means affected by these changes, but we are making it considerably easier for non Symfony2 users, and that's the main reason for these changes. We might make it a bit harder for ourselves by including conditional services, but that's acceptable because otherwise we would have to off-load this complexity to the users, and that must be avoided if we can do so easily. The usability experience of users is important because why would we invest time into writing code just to make it so hard for people to get started, that they will never use it? That makes no sense. KISS clearly states that "unnecessary" complexity should be avoided. The word unnecessary is what we can debate endlessly while on the other hand we have a hard fact, namely the number of people using the component. Kind regards, Johannes -- 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
