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 smile ) 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.

My RoR journey  -- thoughts on learning RoR and lessons learned in applying TDD and agile practices.

Re: A different view on namespace in rails....

"The things you shouldn't be doing in Rails" article has caused quite a ruckus. I think this is due partly to the way it was written and partly to how people perceived it. The first few points in the article mention concrete things you should never do in rails because they have been deprecated. The last few points list some things you shouldn't do in Rails because they aren't handled very well in Rails itself - there are problems. It may help to look at the last few points as a bug report rather than a list of things you should never do.

In theory, namespaces are great. I don't think the author or any Rails expert is against namespaces in general, but is against the way Rails handles controller namespacing. I honestly don't have much experience with them, but I have heard they have some problems. I would prefer to see name spacing fixed in Rails rather than see controller namespacing gone. There is definitely a need for it in some bigger projects.

One reason I think namespaced controllers are discouraged is that they are overused. Beginners often think they are a way for organizing their controllers. Unfortunately we don't live in a perfect world, and more often than not controllers can't be organized in strict categories. Often a controller could exist in multiple categories. Trying to force them into categories early on will probably result in a lot of trouble later on. Anyone who has tried to organize web pages into a menu/hierarchy structure knows that it is very subjective.

Another reason is that they are a sign of duplication. As I learned in the Refactoring to REST article, duplication can easily be hidden across namespaces. A lot of duplicate code was removed by removing the Admin namespace in that example.


I only see two really good reasons to use namespaces. One is if the names conflict as NelsonE mentioned. Another is if there truly is a completely different section of the site which will not have duplication with the rest of the site. Some sites really do have an admin section which needs to be completely separate from the rest of the site. I still say namespacing is used more often than it should.

I think moving namespacing itself into a plugin of some sort would be a good move by the rails core team. For one not many people really need them - only if the project is fairly large and you have naming conflicts. It will also discourage beginners from using it. And, it will hopefully bring more focus to namespacing so it can more easily be improved without cluttering up the Rails core.

Railscasts - Free Ruby on Rails Screencasts