Probably Henrik has gone a bit overboard with the useless files and all, but Benjamin's arguments make sense to me.
The Template (Twig, PHP, Smarty, ..) and the Model (D2 ORM, various D2 ODMs, Propel, Redis, ..) layers are the areas where different people want different things. The rest of the framework is mostly gonna be used by everyone and barely anyone will want to swap out the Form framework or the DIC I suppose. Therefore those Templates and Model layers should be providing integration to the rest, rather than the other way around. There is a clear one way dependency to me. That being said I don't mind if the Form component includes 3 doctrine specific classes, but I think as Benjamin said that the flexibility to register stuff from the outside is required anyway for non-Doctrine, so why not use that for Doctrine. Similarly, the exception templates are written in twig at the moment, and they're located in FrameworkBundle. The Form templates however are in the FrameworkBundle as php templates, and in the TwigBundle as twig templates. I guess you see the problem. I think the exception and form templates should be in the TwigBundle, and then a PHPViewBundle could be added for storing php versions of them for people that don't want to use twig. The WebProfiler templates imo are different, the WebProfiler is a mini "app" and contains its own templates and I think it can have a dependency on twig, you still could disable twig in production and have it only enabled for dev if you want the profiler, or remove the profiler and you can get rid of the TwigBundle as well if you feel like it. Cheers 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. > > 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. > > 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. > > Now with this approach we need to have a two way implementation: > > 1. Special case to get Doctrine working > 2. Common case to allow hooks into Security and Form > > I fail to see how this is KISS. > > greetings, > Benjamin > > On Fri, 28 Jan 2011 13:23:45 +0100, Bernhard Schussek > <[email protected]> > wrote: >> Henrik, >> >> You are entitled to have any opinion that you like. Noone told you >> otherwise. >> >>> Which translated means stuff that you, fabien and bernhard see fit. >> >> The discussions with the community are a great help in shaping a >> picture of how to do things in the best way. Based on these >> discussions and our own experience, we go with the solution that is >> most convincing to us. I can't help it if we fail to see convincing >> arguments in your posts. >> >>> Well if you like it or not people will look at the components for a way >>> to >>> structure their own code so that they have consistency with the > framework >>> they work with. So this will come naturally. >> >> I think you are exaggerating things a lot. Bundles can be independent >> packages, sure. You don't need to build any separate libraries just >> for the sake of it. But at some point _some_ bundles might grow so >> large that it makes sense to extract the Symfony2-independent code. >> That is what we do with the components, and it's good, because users >> of other libraries can easily reuse the code. But it's nothing you >> have to do for every tiny bundle. >> >>> If would very much like to do a PDO implementation if i had the skill > to >>> do >>> it >> >> Ok. Since there's noone else to do it, there is no PDO implementation >> now. Please stop asking for one. >> >>> So you will move the ORM validator(s) to the component but leave the > ODM >>> ones in the bundle? >> >> If we decide to maintain it, we might move ODM support to the core. As >> I said, this needs to be considered once ODM is stable. >> >> Bernhard >> -- >> Software Architect & Engineer >> Blog: http://webmozarts.com >> Twitter: http://twitter.com/webmozart > > -- > 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 > -- Jordi Boggiano @seldaek :: http://seld.be/ -- 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
