As I see it, consistency is an illusion either way, with or without the bundle suffix.
- With the bundle suffix: Acme\BlogBundle @AcmeBlogBundle AcmeBlogBundle:Post:show but it's not AcmeBlogBundle:PostController:showAction - without the bundle suffix Acme\BlogBundle @AcmeBlog AcmeBlog:Post:show but it's not Acme\Blog That leaves me at the original question, what is the benefit of removing the "Bundle" suffix apart from less to write? Having it there is more expressive, it is apparent that we are referring to a bundle here. Especially since we use @ in other places with other meanings, I think readability is more important here than writability. Johannes On Thu, Mar 31, 2011 at 8:58 PM, Kris Wallsmith < [email protected]> wrote: > 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 > -- 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
