@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
