Thanks for mentioning more strange interdependencies, I am not into the view layer much so I cannot make a qualified statement there.
Btw, I see no inconsistency with WebProfiler since its a bundle fro my pov it can have arbitrary dependencies. Its the components dependencies to external libs that feel unconfortable. greetings, Benjamin On Fri, 28 Jan 2011 16:01:46 +0100, Jordi Boggiano <[email protected]> wrote: > 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
