RUBY ON RAILS: RUBY S KILLER APP in Font

Creator Data Matrix 2d barcode in Font RUBY ON RAILS: RUBY S KILLER APP

This is, indeed, what one-to-many relationships with ActiveRecord enable. Setting up such a relationship between models is easy. Consider the two models, located in app/models/entry.rb and app/models/user.rb respectively:

You would use this code for the User model:

ActiveRecord was designed to allow an almost natural language mechanism of defining model relationships. In our Entry model we say that Entry objects belong_to User objects. In the User model we say that User objects has_many associated Entry objects. The only thing you need to set up, other than the relationship itself, is a column in the entries table that enables the relationship to work. You need to store the id of the associated user with each Entry object, so you need to add an integer column to entries called user_id. You could do this by creating a new migration and using a directive such as add_column :entries, :user_id, :integer or by adding the column manually with SQL (or another client). Once the model relationship has been defined and relationships between data have been made which is as easy as, say, entry.user = User.find(1) you can then access data across the relationship. For example, in a view showing an entry, you might have some view code such as this:

ActiveRecord also supports many-to-many relationships. For example, consider the relationship between fictional Student and Class models. Students can be associated with more than one class at a time, and each class can contain many students. With ActiveRecord, you can define these relationships using a join table and a has_and_belongs_to_many relationship, or through an intermediary model such as Enrollment, which defines the links between Students and Classes.

Note It s worth pointing out that a model called Class wouldn t be allowed in Rails, because there s already a class called Class built in to Ruby. Beware of reserved words and using names that are already used elsewhere!

The variety of relationships possible are documented in the official Ruby on Rails documentation at http://www.rubyonrails.org/api/classes/ActiveRecord/ Associations/ClassMethods.html.

A useful feature provided by Rails applications out of the box is support for sessions. When a Web browser makes a request to your application, Rails silently sends back a cookie containing a unique identifier for that browser. Whenever that browser makes further requests, it sends back the cookie with the unique identifier, so the application always knows when a certain previous visitor is making another request. You can use the session s ability to store information that s specific to a particular visitor for use on future requests. Sessions are commonly used on Web sites for features such as shopping carts or keeping track of what pages you ve visited. For example, if you add an item to your cart at an e-commerce site, the item chosen is stored in a data store associated with your session s ID. When you come to check out, your session ID is used to look up data specific to your session in the session system s data store and find out what you have in your cart. To demonstrate basic session storage in your Rails application, you ll count and show a user how many times he or she has accessed actions within your application. To do this, you need to have some way of performing this logic on each request made to the application. You could add logic to every controller action, but an easier way is to use a filter method called before_filter. before_filter is a method you can use at the controller class level to define that a method (or, indeed, many methods) should be executed before the method for the controller action of the current request. Filters make it possible to perform generic activities before every request (or before requests to certain groups of methods or to certain controllers).

Note A common use for filters within Rails is to make sure visitors are authenticated and authorized to

visit certain controllers and perform certain actions. If you have a controller class called AdminController, you might want to add a before_filter that ensures a visitor is logged in to the site as an admin user before you let him or her use the potentially dangerous actions within!

In this example, you ll use before_filter to perform some logic before every request to the application. To do this, you ll add some code to app/controllers/application.rb, so that every controller in your application (although there is only one in this case, entries) will be subjected to the filter.