I agree with Johannes. @AcmeBlogBundle is straight to my brain. ~Amal
On Apr 1, 12:17 am, Johannes Schmitt <[email protected]> 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
