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

Reply via email to