The benefit is consistency — we use the bundle’s logical bundle name universally. k On Thursday, March 31, 2011 at 11:55 AM, Johannes Schmitt wrote: @Kris, could you summarize what the benefit is of removing "Bundle" from the @ references (not from the controller notation)? Is it just less to write, or is there another thing you're trying to fix? > > Thanks, > Johannes > > > On Thu, Mar 31, 2011 at 7:38 PM, Kris Wallsmith > <[email protected]> wrote: > > Thanks for this nice summation, Jordi! > > > > I think this demonstrates the need for us all to disconnect the concept of > > a bundle’s logical name from what we see in the directory structure. The > > example of Acme\BlogBundle is a good one. This bundle’s logical name is > > currently “AcmeBlog,” and was previously “AcmeBlogBundle.” In either case, > > the bundle does not have an ancestor directory by that name, but this is > > the name you need to use if override a resource in app/. > > > > We need to continue using a bundle’s logical name whenever we reference a > > bundle. Whether or not that name includes a “Bundle” suffix is the only > > outstanding issue. > > > > My vote is to omit the “Bundle” suffix and document prominently the concept > > of a bundle’s logical name. > > > > Thanks everyone, > > k > > On Thursday, March 31, 2011 at 9:25 AM, Jordi Boggiano wrote: > > > So, I'll try to summarize the discussion we had on IRC (as unbiased as I > > > can:) > > > > > > For clarity, let's first summarize the various things in play: > > > > > > ================== > > > > > > Bundle Namespace: > > > Acme\BlogBundle > > > > > > Bundle Class: > > > Acme\BlogBundle\AcmeBlogBundle > > > > > > Bundle Name: > > > AcmeBlogBundle (old) > > > AcmeBlog (current) > > > > > > Resource reference: > > > @AcmeBlogBundle/Resources/foo.bar (old) > > > @AcmeBlog/Resources/foo.bar (current) > > > > > > => src/Acme/BlogBundle/Resources/foo.bar > > > => app/Resources/AcmeBlog/foo.bar > > > > > > Template path: > > > AcmeBlogBundle:Default:view.html.twig (old) > > > AcmeBlog:Default:view.html.twig (current) > > > > > > => src/Acme/BlogBundle/Resources/views/Default/view.html.twig > > > => app/Resources/AcmeBlog/views/Default/view.html.twig > > > > > > Action reference: > > > AcmeBlogBundle:Default:view (old) > > > AcmeBlog:Default:view (current) > > > > > > => src/Acme/BlogBundle/Controller/DefaultController.php > > > > > > =================== > > > > > > So according to this, almost everyone agreed that for the Resource > > > references, the current way is confusing, because it doesn't match the > > > filesystem directory. The interesting part is that the old way didn't > > > really match either, only in app/, but not in src/. > > > > > > Now in app/ we have AcmeBlog/, and in src/ Acme/BlogBundle/ - two > > > different things. Maybe splitting it to Acme/ in the app/ dir would > > > help. Maybe adding the Bundle name back in the path would help, then it > > > would actually be equally inconsistent from @AcmeBlog to Acme/BlogBundle/. > > > > > > At this point I could agree that we have to revert the patch for the > > > resources, because it would then be fully consistent, except for the > > > missing / (@AcmeBlogBundle/ => Acme/BlogBundle/), but that's alright. Of > > > course this is difficult unless we make the vendor prefix mandatory. So > > > I guess it should still be AcmeBlogBundle in app, and Acme/BlogBundle in > > > src. > > > > > > The other thing is Template paths, and Action references. As we can see > > > clearly here, both old and current are inconsistent. And app/ and src/ > > > are again inconsistent between each other in a similar way. Also, those > > > don't look like paths, and do much more magic than just changing the > > > prefix of what should come before the @ that you have in resource > > > references. > > > > > > IMO the template and action should remain as they are now, it's shorter > > > and it looks just fine. But one could say that they don't match the > > > directory in app/, nor the one in src/. So again, maybe we should revert > > > that part as well. > > > > > > But in any case, what this has made most apparent to me, is that app/ > > > paths are anyway inconsistent, and the only way to make it look really > > > similar is gonna be to enforce a getVendor() on bundles, that'd take the > > > first namespace bit. I think this would be acceptable. > > > > > > What do you all think? Please read carefully, it all looks very similar. > > > > > > Cheers > > > > > > -- > > > 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 > > > > > -- > > 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 >
-- 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
