Thank you to all of you who took the time to give me feedback on part 1. Most of the feedback was positive. A friend of mine suggested that I drop the sound effects and stick to the subject matter, I graciously accepted his advice. Therefore this post should have a better fact to fluff ratio than the previous one. On that note, let’s begin…
In part 1 we learnt that the routing system has two main functions:
• Interpreting a request URL
• Generating a request URL
Rails uses the same routing rule to interpret a URL and to generate a URL.
Note that routing rules are often called routes, I will use the terms interchangeably.
Now we will start fixing our music_store application from part 1.
About this series
This is a series for beginners wanting to learn about routing in Rails 2.0. This first post is aimed at exploring the behaviour of routing in Rails. It examines what happens when the routing system is given a certain URL. Future posts will examine the ‘hows’ and ‘whys’ of this behaviour. The plan is to start with the basics and move towards the advanced topics. There is only a brief mention of RESTful routing in this post. I plan to delve deeper into that topic at a later stage.
The routing subsystem is at the heart of a Rails application. By looking at the following image, we can see the role of the routing system.
The diagram is a modified version of a diagram found in Flexible Rails.
As the picture depicts, in a Rails application the process begins with a request from the browser. This request is passed into the Rails routing system. The routing system examines the request and is able to determine the following information:
- Which controller to instantiate
- Which action (method) to invoke on that controller
- The parameters, if any, to pass into the action
When receiving a correctly formatted request URL the routing system will instantiate the specified controller, call the appropriate action and pass in the supplied method parameters, if required. The controller will then perform the necessary action and Rails will render the relevant view. This will result in the browser receiving a response and the round trip is complete. This is oversimplified, but it does show the importance of the routing system.
If the request is not in the correct format the routing system may not be able to infer the correct action to take. Therefore it is important that the format is correct. We are in luck as the Rails routing system also helps us to generate requests in the correct format.
In short, the routing system has two main functions:
- Interpreting a request URL
- Generating a request URL
The routing system performs these functions by using routing rules, defined in Ruby code as opposed to XML. The rules can be found in the config/routes.rb Ruby file. Each rule is used to both interpret and to generate a related request URL.
I could go into more theory here but, as with many things, the best way to get to grips with routing is to do it!
Ruby: “Say hello world to my little friend“
Java has Eclipse, .Net has Visual Studio (with ReSharper) and now Ruby has NetBeans! The NetBeans IDE is fast becoming the IDE of choice when it comes to Ruby development. It supports auto-completion, smart navigation and refactoring. In addition to this, NetBeans supports Ruby on Rails!
There are numerous ways to get up and running. In a previous post I suggested Instant Rails as a quick start. You can use NetBeans and Instant Rails together; Brian Leonard’s Blog explains how to do this. If you download the Ruby bundle of NetBeans you can skip some of the steps in Brian Leonard’s tutorial.