You can go as deep with nested routes as you want, but keep in mind that just because you can doesn't mean you should. The deeper you dig, the more work you're creating for yourself.
The pattern I've seen is that for each level of depth, you need to create a base controller which handles the parent parameters, and a subclass which handles the specifics. This tends to play out along the lines of:
Customer::BaseController < ApplicationController
CustomerController < CustomerController:: BaseController
Customer::Orders::BaseController < Customer::BaseController
Customer::OrdersController < Customer::Orders::BaseController
Customer::Orders::Items::BaseController < Customer::Orders::BaseController
Customer::Orders::ItemsController < Customer::Orders::Items::BaseController
The BaseController in each case handles the loading and interpreting of parameters in a generic manner, such as:
class Customer::BaseController < ApplicationController
before_filter :load_customer
protected
def load_customer
@customer = Customer.find(params[:customer_id] || params[:id])
rescue ActiveRecord::RecordNotFound
render(:partial => 'customer_not_found', :layout => 'application', :status => :not_found)
end
end
As you can see it can get a little convoluted if you map out your application in this manner. You end up with really long routes as well.
If your database is designed so that the records are fairly autonomous, and a lot of the relationship information can be divined from them, then you don't necessarily need to go to all this trouble. An order page can provide linkages to @order.customer without having to have customer_id in the path.