Modify the trails model and the Location model to reflect the new relationships, like this: class Trails < ActiveRecord::Base belongs_to :location end class Locations < ActiveRecord:
Trang 1adding Austin, Texas, and Durango, Colorado
It's time to write some code ourselves, instead of letting Rails do all the work You're going to need to update your trails table to point to the right row in the new locations table You'll do so by adding a new database column that points
to location_id, like this:
alter table trails add location_id int(6);
You also need to tell Rails about the relationship Modify the trails model and the Location model to reflect the new relationships, like this:
class Trails < ActiveRecord::Base
belongs_to :location
end
class Locations < ActiveRecord::Base
has_many :trails
end
Figure 7-1 This application has less than 10 lines of code and configuration,
because Rails inferred the structure from the database
A little description here is interesting You've created a subclass of the
ActiveRecord class in the Base module You've then fired a method called belongs_to and passed it a symbol for the Locations class This method will fire more metaprogramming code that actually adds the properties and methods to your code that will manage the relationships for you
Next, you're going to have to edit the trails view and controller to edit a
location The scaffolding created the new controllers and views under trails and locations, respectively
It's time to modify some of the view code The view code consists of HTML, with Ruby scripting mixed in, between the <% and %> tags First, you'll need to make sure the view has all the information it needs You'll do this in the edit method,
in the controller Change the edit method in trails_controller.rb to create a
property called @locations that has all the locations:
class TrailsController < ApplicationController
Trang 2
def edit
@trail = Trail.find(@params[:id])
@locations = Location.find_all
end
end
It's also time to take over the full view that lets you edit a trail You'll want the user
to pick a location from a pick list with all possible locations Change
app/views/trails/edit.rhtml to look like this:
<html>
<head><title>Edit a Trail</title></head>
<body>
<h1>Edit Trail</h1>
<form action=" /update" method="POST">
<input id="trial_id" name="trail[id]" size="20"
type="hidden" value="<%= @recipe.id %>" />
<p><b>Name</b><br>
<input id="trail_name" name="trail[name]" size="20"
type="text" value="<%= @trail.name %>" />
</p>
<p><b>Location:</b><br>
<%= collection_select("trail", "location_id", @locations, "id","city") %>
<p><b>Description</b><br>
<textarea cols="40" id="trail_description"
name="trail[description]"
rows="20" wrap="virtual">
<%= @trail.description %>
</textarea> </p>
<input type="submit" value="Update" />
</form>
<a href="/trail/show/<%= @trail.id %>">
Show
</a> |
<a href="/trail/list">
Back
</a>
</body>
Trang 3</html>
As with most applications, your scaffolding won't hold up infinitely Often you'll want to replace most of the view code Rails lets you build toward the goal, instead
of creating all of a model, view, and controller right off the bat
Notice the code in bold It adds an option value for all the locations (which you specified in the edit method of the controller), and selects the one that matches the one that reflects the model, shown in the variable
trails.location.city
Finally, you'll need to show the new data in the trail list, and in the show method The idea is exactly the same Add a line to the show.rhtml view right above the links on the bottom of the page:
<p>
<b>Location:</b> <%=h @trail.location.city %>
</p>
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:
<table>
<tr>
<th>Name</th>
<th>Location</th>
</tr>
<% for trail in @trails %>
<tr>
<td><%= trail.name %></td>
<td><%= trail.location.city %></td>
<td><%= link_to 'Show', :action => 'show', :id => trail %></td>
<td><%= link_to 'Edit', :action => 'edit', :id => trail %></td>
<td><%= link_to 'Destroy', {:action => 'destroy', :id => trail}, :
confirm => "Are you sure?" %></td>
</tr>
<% end %>
</table>
Trang 4Figure 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
7.3 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
Trang 57.3.1 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
7.3.1.1 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
7.3.1.2 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
7.3.1.3 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
7.3.1.4 Inheritance
Trang 6Inheritance works, putting all subclasses in a single table with the parents:
class Product < ActiveRecord::Base
end
class Bike < Product
end
7.3.1.5 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 You can look at the metadata for the columns for a table, and support multiple database types It also provides support that makes it easy for you to build test fixtures Active Record is a powerful framework and a credible competitor to Java's ORM frameworks
7.3.2 Action Pack
Action Pack deals with requests in two parts: the controller and the view Requests come into Action Pack through a dispatcher The dispatcher routes the request to a controller, which invokes any model logic and sends the request to a template-driven view system The template engine fires the Ruby template, which may execute Ruby code, and returns the resulting HTML to the browser The flow, shown in Figure 7-3, is reminiscent of Struts There are a few differences For example, the controller has a group of actions, instead of encapsulating each action
in a different class If you wanted to refactor, you'd let actions share methods Figure 7-3 Ruby on Rails is actually made up of several existing frameworks,
most notably Active Record and Action Pack
Trang 7The Action Pack splits the request into a controller part and a view part With Rails, a whole lot happens automatically In some ways, that's bad You can't see all the methods or the attributes on your class, and you don't even know what they are unless you look at the database In other ways, it's a highly productive way to work You can change your model, schema, and view in many cases just by adding columns to the schema Let's take a fuller look at the capabilities of Action Pack 7.3.2.1 Capabilities
Action Pack goes beyond simple request processing It contains many capabilities that make it easier to develop web applications I'll touch on some of the major capabilities here
As you've seen, Action Pack uses Ruby as the scripting language Java developers frown on embedding Java into a JSP, but I'd suggest that code will be in the view regardless of whether it's in Ruby Early on, some vocal zealots overreacted to the early proliferation of Java scriptlets and decreed that MVC means "no code on the page." Many Ruby developers believe that code that is concerned with the view (and only the view) does belong on the page Burying Java code in a custom tag only complicates and confuses the issue
Ruby provides a far friendlier scripting language than JSTL tags, for example Like
Trang 8servlets, Action Pack lets you attach filters for things like authentication Action Pack also handles some convenience design elements, like automatically
paginating your result sets and providing navigation links
Action Pack also has some features that make it easier to build components, like helper classes (to render a date, for example), a layout sharing feature (similar to Tiles, if you're familiar with Struts), intracomponent communication, and pretty good Ajax integration Like Struts and Spring, Action Pack provides good support for building and validating forms
You'll need to manage your solution, and Action Pack builds in some features to help It enables logging, caching at three levels (page, action, and fragment), and benchmarking support Developers can use integrated support for unit testing and debugging It's not as powerful as Struts in some ways, but it's much simpler, and highly customizable