I think we’re on the same page. I prefer omitting the suffix but the would be okay with its inclusion. My primary concern is that we use the logical bundle name universally — that’s what I mean by consistency. k On Thursday, March 31, 2011 at 12:17 PM, Johannes Schmitt wrote: 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 >
-- 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
