Beyond Java - Bruce Tate [70]
Location: <%=h @trail.location.city %>
That's pretty simple. You're just getting the location from the model passed in by the controller. The list view uses the same technique. You can edit the table from the app/views/trails/list view:
| Name | Location | |||
|---|---|---|---|---|
| <%= trail.name %> | <%= trail.location.city %> | <%= link_to 'Show', :action => 'show', :id => trail %> | <%= link_to 'Edit', :action => 'edit', :id => trail %> | <%= link_to 'Destroy', {:action => 'destroy', :id => trail}, : confirm => "Are you sure?" %> |
Figure 7-2 shows you the result, with the location of each trail in the main list. Keep in mind that all trails have to have locations. If one of yours doesn't, you will get an error here.
This tutorial has already gone on long enough, but I hope you can appreciate the power and flow of Rails development. You can quickly get your application rolling, because Rails discovers your application structure from
Figure 7-2. This list comes from an application that allows you to view and update a database, with trails in one table and locations in another
the database design. You then turn changes around quickly, because the feedback cycle requires you only to code/reload. You're building quality beyond what PHP can give you, because you're building with a proven model/view/controller design pattern, with built-in features for logging, caching, and automated testing. Now that you've seen what Rails can do, take a look under the hood to see some of this magician's secrets.
Under the Hood
As you've seen, the Rails framework is also made up of several existing frameworks, including Active Record, Action Pack, and a few others. Active Record handles relational database access. Action Pack processes requests, and manages the model/view/controller separation. Rails provides the integration and the rest.
Active Record
Active Record implements the Active Record design pattern by Martin Fowler in Patterns of Enterprise Application Architecture (Addison Wesley). It's effectively a wrapper around a database table, with domain logic built into the wrapper. The Rails implementation adds two important innovations: you can do inheritance and manage relationships. These are some of the major features.
Automatic properties
Active Record automatically adds properties, with accessors, to model objects. It also adds methods for simple CRUD database methods automatically. For example, in the view you just wrote, the view accesses the name property in Trail, though the root model was empty:
class Trail < ActiveRecord::Base
end
Association management
Rails uses methods to add methods that manage associations, automatically. You saw this example where a location has many trails:
class Location < ActiveRecord::Base
has_many :trails
end
As you have seen, has_many is a method, and :trails is a symbol, in this case, for the Ruby class Trails.
Composition
You can use Active Record to compose objects from multiple tables, like this:
class Location < ActiveRecord::Base
composed_of :street, :class_name => "Street",
:mapping => %w(street name)
end
Inheritance
Inheritance works, putting all subclasses in a single table with the parents:
class Product < ActiveRecord::Base
end
class Bike < Product
end
Other features
Of course, a full Active Record discussion is beyond the scope of this book, but these are some of the other features you can use. You can build recursive relationships, like trees. You can use Active Record to validate certain types of rules (for instance, there must be an existing location for a new trail). Active Record can notify an email address when some significant event happens.
Active Record also has good plumbing. It supports transactions and error logging.