Getting the namespace out of the URL

I want to group my controllers into subdirectories as a matter of
internal organization, but I do not want to have these subdirectories
automatically interpreted as some latent desire on my part to create
additional namespaces. Ideally, these “nested” controllers should
continue to behave as if they were right at the root of my controllers
directory without any extra prefixes attached to any URLs.

For example:

app/controllers/subdir1/foo_controller.rb

should be accessible via

/foo/index

NOT

/subdir1/foo/index

I understand why namespaces are a very useful feature in many
situations, mine simply doesn’t happen to be one of them. Is there any
way to shut this off, or at least specify a default namespace in a
generic catch-all style route?

Thanks.

On Tue, Mar 3, 2009 at 12:47 PM, khiltd [email protected] wrote:

app/controllers/subdir1/foo_controller.rb
situations, mine simply doesn’t happen to be one of them. Is there any
way to shut this off, or at least specify a default namespace in a
generic catch-all style route?

Have you tried something like this already?

%w( dir1 dir2 dir3 ).each do |d|
%w( controller1 controller2 ).each do |c|
map.connect “#{ c }”, :controller => “#{ d }/#{ c }”
end
end

or maybe add a slash if that doesn’t work:

map.connect “/#{ c }”, :controller => “#{ d }/#{ c }”


Greg D.
http://destiney.com/

Why not make it a shallow route?

in your routes.rb file do

namespace.resources :foo, :shallow => ‘true’

Then rake routes and check that it’s had the desired effect with no
errors (routes with the same name etc)

http://guides.rubyonrails.org/routing_outside_in.html

On Mar 4, 1:51 am, Gavin [email protected] wrote:

Why not make it a shallow route?

in your routes.rb file do

namespace.resources :foo, :shallow => ‘true’

Then rake routes and check that it’s had the desired effect with no
errors (routes with the same name etc)

There are no resources, and that most definitely does not work.

On Mar 4, 1:59 am, Gavin [email protected] wrote:

http://guides.rubyonrails.org/routing_outside_in.html

Yes, I have read that several times. To quote the relevant section
regarding the :shallow option

“paths for nested resources which reference a specific member (that
is, those with an :id parameter) will not use the parent path prefix
or name prefix.”

Without an :id, the option is meaningless.

On Mar 3, 6:46 pm, Greg D. [email protected] wrote:

map.connect “/#{ c }”, :controller => “#{ d }/#{ c }”


Greg D.http://destiney.com/

That’s unfortunately not very “DRY” and I’d rather not clutter up the
dispatch table with dozens of nigh identical routes. It runs slowly
enough as it is.

You can try adding a line to your config/environment.rb, like so:

config.load_paths += %W( #{RAILS_ROOT}/app/controllers/subdir )

Pros: This way you can define controllers normally, outside a Subdir
module, and they’ll act as normal.
Cons: You’ll have to add things to your load path manually.

Diogo

On Mar 4, 10:14 am, Diogo L. [email protected] wrote:

You can try adding a line to your config/environment.rb, like so:

config.load_paths += %W( #{RAILS_ROOT}/app/controllers/subdir )

That was actually the first thing I tried and it has absolutely no
effect. The problem is not that the controllers fail to load, it’s
that the dispatcher interprets all path separators in their names as
nested module definitions whether you like it or not.

On Wed, Mar 4, 2009 at 4:10 PM, khiltd [email protected] wrote:

On Mar 4, 10:14Â am, Diogo L. [email protected] wrote:

You can try adding a line to your config/environment.rb, like so:

 config.load_paths += %W( #{RAILS_ROOT}/app/controllers/subdir )

That was actually the first thing I tried and it has absolutely no
effect. The problem is not that the controllers fail to load, it’s
that the dispatcher interprets all path separators in their names as
nested module definitions whether you like it or not.

I tested this on 2.2.2. Worked as I described. Try it out on a new
project and see what happens.

Diogo

On Mar 4, 11:23 am, Diogo L. [email protected] wrote:

I tested this on 2.2.2. Worked as I described. Try it out on a new
project and see what happens.

Then I guess I’ll file a bug against 2.3 because it definitely doesn’t
work now.