views:

61

answers:

3

I'm trying to move past the beginner stage of Rails and into the intermediate but I'm finding it hard to find more advanced examples to learn from.

For example, I've read that you need to be careful about "Nested Routes" and shouldn't go more than 2 deep. What happens in a situation like this?

  • Customer can place many Orders
  • Orders can have many Items
  • Items can have many types of Options
  • Each type of Option can have restrictions: available on certain days, or requires a selection, or affects total price, etc.

Is this a fools errand or simple stuff for Rails. I'm assuming the latter but can't find any interesting example projects (source) out there to learn from? Books seem to stop at the basics... ideas?

+2  A: 

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.

tadman
+1  A: 

Hm, I agree with you that many books start and stop at basics.

But if you're bored you should sit down and develop an idea. It is always the best fun if you're working on a real project. Learning from examples and unreal scenarios may help for some time, but at some point it's time to get some challenge.

Personally speaking I stopped reading books after finishing "Agile Web Development with Rails". Then I started making my own failures and learned from them.

Theoretically speaking, you can try to prepare yourself for every 'intermediate' or 'advanced' situation you might get into.

Honestly speaking, the fights I've fought with problems in my way weren't related to any theoretical scenario found in books. I had to sit down, track the problem, read backtraces, think about them, google for similar problems, write tests... This is what really helped me gaining experience.

Go out there and find or develop an idea. If you got one, write tests and try implementing it. This will give you the boost, you are maybe looking for.

Note: http://github.com is a great place to find source code to look at & learn from.

Overbryd
A: 

Have a look at opensourcerails.com - find an app that interests you, grab the source, and go through it piece by piece. Run it locally, find the interesting functionality, then get into the code to see how its done.

nfm