I'm not saying Benjamin's arguments are null and void, but we have basically two fundamentally different perspectives on this.
The first perspective is from a developer's point how to semantically best express the dependencies between the different parts of the code. The other perspective is from a business point how to make the components as attractive as possible so they get used by as many people as possible. We will not be able to satisfy both view points 100%, there will be a trade-off. To understand the problem, we basically have two target groups: - Symfony2 Framework Users: * Our primary concern * for these it will only be namespace changes, nothing spectacular * new users won't even notice this - Symfony2 Component Users without the Framework: * Our secondary concern * the components must bring value for them if we want to see them used, and we do want ;) * in order for components to bring value, they need to be usable * having to write 1500 LOC before it is usable is not good enough * having complex installation procedures will not help either Btw, we are in good company with the approach we have outlined above. Spring is taking the same stand, and I don't think that you want to claim that all the Spring engineers don't know what they are doing ;) Kind regards, Johannes On 28 Jan., 16:06, Benjamin Eberlei <[email protected]> wrote: > 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/Doct... > > > > >> 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
