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, TN
http://www.iostudio.com
http://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

Reply via email to