Topic: A different view on namespace in rails....
Namespaced controllers were one of the items on the "Things you shouldn't be doing in Rails" (our thread here) and its one of the items I object to, but not in the "I like my Admin namespace" that many people use. I'd like to try to explain my view and see if others can help me fine-tune the argument or help me see the "error of my ways." First some "philosophical musings" then some semi-concrete (glass? -- easily broken ) examples. I understand that Rails has grown by extraction from existing systems and that some of what I'm doing is the "what if/hand-waving" that is in some sense diametrically opposed to that tradition. However the result of that tradition, might greatly complicate the development of a successive system that exhibits the utility of better namespace support in Rails...
Namespaces are critical for adequately breaking up large projects into manageable pieces. Ruby has wonderful namespace support. Rails itself makes a lot of use of namespaces to keep its own house in order -- you can see the large number of modules used for code share and namespacing throughout the source code. Given that the developers of Rails found namespaces useful for Rails, I find it odd that they feel its not needed in applications built with Rails.
One of the counter arguments against namespaced controllers is that you don't have namespaced models. I find that there are at least two flaws in this statement. First, it assume a 1:1 mapping of controllers to models -- something that might be an axiom in a RESTful system, but not in a general Rails application. The more fundamental issue is that it uses one flaw to impose another. There are good reasons why models should be support namespaces as well.
For instance (start of the semi-concrete examples):
Lets say you're working on a Rails system that needs to talk to multiple (legacy) databases and lets say further that these databases have some tables with identical names. Wouldn't it be nice to stick each set of tables into its own namespace? Or course you'll still do some of the normal tricks for working with multiple databases -- base classes with the appropriate database connection, etc, but the point is now you could theoretically use the standard rails convention over configuration to talk to the two databases. Without the namespaces you'd be stuck playing games with the names of the models and overriding the :tablename in the class -- ie adding configuration. (And this by extension would push for namespace controllers if you wanted to do nice RESTful things in the controllers...)
Even without multiple database, in "large" databases with 50-200+ modeled tables, you might want to create "clumps" of models, if you have multiple developer teams generally non-overlapping portions of the site. Think about some of the larger e-commerce or portal type applications with generally disjoint areas only partially really interconnect. (I know in some sense theses aren't Web 2.0 as they are small, tightly focused, but I still see Rails as being useful for them)
Turning to controllers, in "isolation" of the affiliated models; I understand both sides of the "Admin" argument. If that were the only place I could see namespaces being useful, I'd personally feel it was a weak case, but I'ld probably still want them. However, the same portal/mega-site comments from before still appear here. It would be nice to be able to re-use names in different areas of the application. Yes you can effectively alias controllers via routes so that your urls appear namespaced even if the underlying controllers aren't, but that still means that the names of the controller classes are forced to be globally unique, not namespaced unique.
Some people, rather than having the "Admin" namespace, might want to have an "AdminController" in each of several namespaces. In a non-RESTful system there are plenty of other common words that appear as controllers -- Register (for an account on the website, for a course, etc),. Yes in most cases you can find synonyms or alternate forumulationss, but then you start getting into places where the naming is be forced away from the clear intention of the code in order to only satisfy uniqueness concerns. From a code browser/documentation viewpoint, I'd rather see "Accounts::RegisteControllerr" and "Courses::RegisterController" than someone trying to be "clever" with "SignupController" and "EnrollmentController" or similar in the global namespace. And I would personally find it even worse if one were left as "RegisterController" and the other shunted aside as I feel that really violates least surprise. And if you start with "AccountRegisterController" and "CoursesRegisterController" you're only demonstrating the need for namespaces directly. Clear, concise names; naming with intention is an critical part of agile development. Artificially complicating naming due to lack of namespaces seems to be a limitation.
I hope this doesn't come across as a flame or an attack, but I just haven't been able to understand the anti-namespace bias that seems to exist within the experienced rails developers.