views:

338

answers:

3

The situation is simple. In Rails 2.3.3, I've got a "Staff" namespace, and controllers in there inherit from the StaffController. That StaffController itself handles the Staff namespace's root:

map.namespace :staff do |staff|
  staff.root  :controller=>'staff',
              :action=>'index'
  # ...
end

In development mode, that works fine. In production mode, however, this breaks:

uninitialized constant Staff::StaffController

among other issues, such as certain helpers rendering incorrectly in the Staff namespace.

Why do development and production mode act behave differently in this context, and what can I do to fix it?

A: 

What does your production environment look like? Passenger/Apache? Latest version (2.2.4)? Inconsistencies like that have typically been a stack problem for me as opposed to a code problem, so couldn't hurt to start there.

bensie
It's Passenger on the actual deploy server, but I also ran production on my own server, too - even on WEBrick, the same errors occur.
Matchu
+1  A: 

What happens if you run rake routes in both production and development modes?

That might help you narrow it down to (as bensie mentioned) a hosting stack vs. framework/code issue.

Rufo Sanchez
The relevant line is the same: staff_root, /staff. {:controller=>"staff/staff", :action=>"index"} - I get the feeling that maybe it's not a glitch in production, but a glitch in development that this setup is even working at all. Maybe I'll try moving the staff's root page to a different controller and see what happens.
Matchu
Alright, good. Seeing that the routes in both cases pointed to "staff/staff" helped me see where I needed to go, and now the staff namespace root now has its own controller. Thanks!
Matchu
A: 

It seems you've solved this already, but two things to watch out for:

  1. Some subtle changes can happen when using Apache vs Webrick/Mongrel (best practice would be to actually setup Apache+Passenger locally for development

  2. In certain deployment situations you can shoot yourself in the foot when you implement a conditional route and make a db migration happen at the same time (best practice would be to wrap the conditional route in a check for the DB migration. This may mean that you need to do a second restart of your server after load and migration, but still better than the alternative.

Mike Buckbee