Thank you for your answer Ryan. I see how giving descriptive names to bundles, prefixed with the vendor name is about the same in avoiding collisions, and when specifying controllers in routes. However, in my opinion it is counter- intuitive to define a PHP class FooVendor\BarPackage \FooVendorBarPackageBundle or at least somewhat disappointing for a next-gen PHP framework, which in every other regard is benefiting from namespaces.
Also in this (admittedly early) stage, I'm under the impression that this practice is not well adopted in the bunch of public bundles being developed already. I've seen AdminBundles, BlogBundles, TwitterBundles etc. Given that Bundles are just as well used for the plugin type of functionality we loved in sf1, it bothers me a little. Concerning the flexibility in naming controller classes, I don't have major issues with having some framework conventions to that regard, but if controllers would be identified by a FQN as suggested above, afaik there no longer would be a need for this hardcoding, so I do see it as another added benefit. For the template part you are probably right. As I said I did not look very deep into that part yet, so I suppose it is quite flexible. But again, my concern would be dropping in a third-party bundle/package of bundles and suddenly have clashing template identifiers (in the default configuration) because the bundles were not named following the "best practices". Have a nice day. Gerry. On Feb 24, 5:13 am, ryan weaver <[email protected]> wrote: > Hey Gerry- > > I think the answer to most of your concerns relates to being friendly to > rapid development, though, none of these things you're saying end up > actually being forced on you (they're just conventions). > > First, the bundle names. This is really a matter of preference. At the end > of the day, we decided that all bundle names should be unique (there are > several reasons for this). That could have been accomplished by using the > fully-qualified name of a bundle (Sensio\HelloBundle) or by the current > convention (SensioHelloBundle). I don't know exactly why we landed on the > latter, but they're quite similar. In both cases, there should be no unique > problems as the bundle name follows the namespace. > > Second, controllers. The string convention you normally see - > SensioHelloBundle:Hello:index - indeed translates into the class > Sensio\SensioHelloBundle\Controller\HelloController. For ease, that is > indeed hardcoded. However, this is just an optional convention to make life > easier. You can also make your controller a service and then refer to it > directly as its service name. For example, if your controller is named > (hello_controller), you can use that string in your routing configuration > (or anywhere else you refer to the controller). So, convention makes life > easier - but you have full flexibility if you go the service route. > > Finally, templates. This is hardcoded inside the "TemplateNameParser" class > and later really the "TemplateReference". This is a convention that gives > you a considerable bit of flexibility, but if you ever needed to modify this > functionality, you could create your own TemplateNameParser and swap yours > in via the dependency injection container. > > Does that answer your questions? Making Symfony2 completely flexible (while > still very useful for rapid development) is definitely a major goal of the > framework. > > Thanks! > > Ryan Weaver > Lead Programmer - iostudio - Nashville, > TNhttp://www.iostudio.comhttp://www.thatsquality.com > Twitter: @weaverryan > > > > On Tue, Feb 22, 2011 at 9:01 AM, Gerry <[email protected]> wrote: > > Hello, > > > The past few days I have been looking into Symfony2 and I had some > > concerns regarding the lack of flexibility in naming Controllers and > > possible naming collisions for Bundles. > > > While every single class in Sf2 is namespaced, it struck me that > > controller names in routes and template names are not fully qualified > > and ambiguous when you have more than one Bundle with the same name. > > While I understand your best practices for naming Bundles try to work > > around that, I do feel it's counter-intuitive (as the Bundle is > > already properly namespaced), and I do not understand why not specify > > a fully qualified controller name to start with, as it's only slightly > > more verbose and avoids any ambiguity. > > > Another related concern is about the flexibility of naming > > controllers, as currently a pattern of NameSpace\BundleName\Controller > > \FooController is hard-coded in ControllerResolver.php, leaving little > > flexibility to that regard. Again, using fully qualified names for the > > controllers would avoid this issue. > > > The problem also extends to view names, though I haven't had the > > chance looking further into that part. > > > Regards, > > Gerry. > > > -- > > 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
