railsspace building a social networking website with ruby on rails phần 8 pps

Previous tests of forms have involved posting information like this: post :login, :user => { :screen_name => user.screen_name, :password => user.password } What we want for an avatar tes

eventual system call to the underlying convert executable will look something likethis:

system("#{convert} ")

The appropriate value ofconvert(with full path name) will automatically be lated into the string used for the system call

Now that we know how to convert images, we come finally to the Avatarsavemethod

saveitself is somewhat of an anticlimax, since we push the hard work into an auxiliaryfunction calledsuccessful _ conversion?:

# Try to resize image file and convert to PNG.

# We use ImageMagick's convert command to ensure sensible image sizes.

def successful_conversion?

# Prepare the filenames for the conversion.

source = File.join("tmp", "#{@user.screen_name}_full_size")

full_size = File.join(DIRECTORY, filename)

thumbnail = File.join(DIRECTORY, thumbnail_name)

# Ensure that small and large images both work by writing to a normal file.

# (Small files show up as StringIO, larger ones as Tempfiles.)

File.open(source, "wb") { |f| f.write(@image.read) }

# Convert the files.

system("#{convert} #{source} -resize #{IMG_SIZE} #{full_size}")

system("#{convert} #{source} -resize #{THUMB_SIZE} #{thumbnail}")

File.delete(source) if File.exists?(source)

# No error-checking yet!

return true

successful _ conversion?looks rather long, but it’s mostly simple We first define

file names for the image source, full-size avatar, and thumbnail, and then we use the

systemcommand and ourconvertmethod to create the avatar images We don’t need

to create the avatar files explicitly, sinceconvert does that for us At the end of the

function, we returntrue, indicating success, thereby following the same convention as

Active Record’ssave This is bogus, of course, since the conversion may very well have

failed; in Section 12.2.3 we’ll make sure thatsuccessful _ conversion?lives up to its

name by returning the failure status of the system command

The only tricky part ofsuccessful _ conversion?touches on a question we haven’t

yet answered: What exactly is an “image” in the context of a Rails upload? One might

expect that it would be a Ruby File object, but it isn’t; it turns out that uploaded

images are one of two slightly more exotic Ruby types:StringIO(string input-output)

for images smaller than around 15K andTempfile(temporary file) for larger images

In order to handle both types, we include the line

File.open(source, "wb") { |f| f.write(@image.read) }

to write out an ordinary file so thatconvertcan do its business.10File.openopens a

file in a particular mode—"wb"for “write binary” in this case—and takes in a block in

which we write the image contents to the file using@image.read (After the conversion,

we clean up by deleting the source file withFile.delete.)

The aim of the next section is to add validations, butsavealready works as long as

nothing goes wrong By browsing over to an image file (Figure 12.3), we can update the

hub with an avatar image of our choosing (Figure 12.4)

12.2.3 Adding validations

You may have been wondering why we bothered to make the Avatar model a subclass

of ActiveRecord::Base The answer is that we wanted access to the error handling

and validation machinery provided by Active Record There’s probably a way to add this

functionality without subclassing Active Record’s base class, but it would be too clever by

half, probably only serving to confuse readers of our code (including ourselves) In any

case, we have elected to use Active Record and its associatederrorobject to implement

validation-style error-checking for the Avatar model

10convertcan actually work with tempfiles, but not with StringIO objects Writing to a file in either case

allows us to handle conversion in a unified way.

Figure 12.3 Browsing for an avatar image.

The first step is to add a small error check to thesuccessful _ conversion?tion By convention, system calls returnfalseon failure andtrueon success, so wecan test for a failed conversion as follows:

# Convert the files.

img = system("#{convert} #{source} -resize #{IMG_SIZE} #{full_size}")

thumb = system("#{convert} #{source} -resize #{THUMB_SIZE} #{thumbnail}")

File.delete(source) if File.exists?(source)

# Both conversions must succeed, else it's an error.

unless img and thumb

errors.add_to_base("File upload failed Try a different image?")

Figure 12.4 The user hub after a successful avatar upload.

rather than simply errors.addas we have before, which allows us to add an error

message not associated with a particular attribute In other words,

errors.add(:image, "totally doesn't work")

gives the error message “Image totally doesn’t work”, but to get an error message like

“There’s no freaking way that worked” we’d have to use

errors.add_to_base("There's no freaking way that worked")

This validation alone is probably sufficient, since any invalid upload would trigger

a failed conversion, but the error messages wouldn’t be very friendly or specific Let’s

explicitly check for an empty upload field (probably a common mistake), and also make

sure that the uploaded file is an image that doesn’t exceed some maximum threshold

(so that we don’t try to convert some gargantuan multigigabyte file) We’ll put thesevalidations in a new function calledvalid _ file?, and then call it fromsave:

unless @image.content_type =~ /^image/

errors.add(:image, "is not a recognized format")

Does Rails really let you write1.megabytefor one megabyte? Rails does

11 The carat ^ at the beginning of the regular expression means “beginning of line,” thus the image content type must begin with the string "image"

Since we’ve simply reused Active Record’s own error-handling machinery, all we need

to do to display error messages on the avatar upload page is to useerror _ messages _ for

as we have everywhere else in RailsSpace:

The last bit of avatar functionality we want is the ability to delete avatars We’ll start by

adding a delete link to the upload page (which is a sensible place to put it since that’s

where we end up if we click “edit” on the user hub):

[<%= link_to "delete", { :action => "delete" },

:confirm => "Are you sure?" %>]

.

.

.

We’ve added a simple confirmation step using the :confirm option to link _ to

With the string argument as shown, Rails inserts the following bit of JavaScript into

the link:

Figure 12.5 The error message for an invalid image type.

This uses the native JavaScript function confirm to verify the delete request(Figure 12.6) Of course, this won’t work if the user has JavaScript disabled; in thatcase the request will immediately go through to thedeleteaction, thereby destroying

the avatar C’est la vie.

As you might expect, thedeleteaction is very simple:

Listing 12.18 app/controllers/avatar controller.rb

Figure 12.6 Confirming avatar deletion with JavaScript.

redirect_to hub_url

end

end

This just hands the hard work off to thedeletemethod, which we have to add to the

Avatar model Thedeletemethod simply usesFile.deleteto remove both the main

avatar and the thumbnail from the filesystem:

Listing 12.19 app/models/avatar.rb

.

.

.

Before deleting each image, we check to make sure that the file exists; we don’t want

to raise an error by trying to delete a nonexistent file if the user happens to hit the

/avatar/deleteaction before creating an avatar

12.2.5 Testing Avatars

Writing tests for avatars poses some unique challenges Following our usual practicepost-Chapter 5, we’re not going to include a full test suite, but will rather highlight aparticularly instructive test—in this case, a test of the avatar upload page (including thedelete action)

Before even starting, we have a problem to deal with All our previous tests havewritten to a test database, which automatically avoid conflicts with the developmentand production databases In contrast, since avatars exist in the filesystem, we have tocome up with a way to avoid accidentally overwriting or deleting files in our main avatardirectory Rails comes with a temporary directory called tmp, so let’s tell the Avatarmodel to use that directory when creating avatar objects in test mode:

DIRECTORY = File.join("public", "images", "avatars")

end

.

.

.

This avoids clashes with any files that might exist inpublic/images/avatars

Our next task, which is considerably more difficult than the previous one, is to

simulate uploaded files in the context of a test Previous tests of forms have involved

posting information like this:

post :login, :user => { :screen_name => user.screen_name,

:password => user.password }

What we want for an avatar test is something like

post :upload, :avatar => { :image => image }

But how do we make an image suitable for posting?

The answer is, it’s difficult, but not impossible We found an answer on the Rails wiki

(http://wiki.rubyonrails.org/), and have placed the resultinguploaded _ file

function in the test helper:

Listing 12.21 app/test/test helper.rb

# Simulate an uploaded file.

(class << t; self; end).class_eval do

alias local_path path

We are aware that this function may look like deep black magic, but sometimes it’s

important to be able to use code that you don’t necessarily understand—and this is one

of those times The bottom line is that the object returned byuploaded _ filecan be

posted inside a test and acts like an uploaded image in that context

There’s only one more minor step: Copy rails.pngto the fixtures directory sothat we have an image to test.

> cp public/images/rails.png test/fixtures/

Apart from the use ofuploaded _ file, the Avatar controller test is straightforward:

Listing 12.22 test/functional/avatar controller test.rb

require File.dirname( FILE ) + '/ /test_helper'

require 'avatar_controller'

# Re-raise errors caught by the controller.

class AvatarController; def rescue_action(e) raise e end; end

class AvatarControllerTest < Test::Unit::TestCase

image = uploaded_file("rails.png", "image/png")

post :upload, :avatar => { :image => image }

Here we’ve tested both avatar upload and deletion

Running the test gives

This page intentionally left blank

C HAPTER 13

Email

In this chapter, we’ll learn how to send email using Rails, including configuration,email templates, delivery methods, and tests In the process, we’ll take an opportunity torevisit the user login page in order to add a screen name/password reminder, which willserve as our first concrete example of email We’ll then proceed to develop a simple emailsystem to allow registered RailsSpace users to communicate with each other—an essentialcomponent of any social network We’ll see email again in Chapter 14, where it will

be a key component in the machinery for establishing friendships between RailsSpaceusers

in a controller to send email based on user input

The purpose of this section is to turn these abstract ideas into a concrete example byconfiguring email and then implementing a screen name/password reminder

389

13.1.1 Configuration

In order to send email, Action Mailer first has to be configured The default

configura-tion uses SMTP (Simple Mail Transfer Protocol) to send messages, with customizable

You will need to edit the server settings to match your local environment, which will

probably involve using your ISP’s SMTP server For example, to use DSLExtreme (an

ISP available in the Pasadena area), we could use the following:

There’s one more small change to make: Since we will be sending email in thedevelopment environment, we want to see errors if there are any problems with the maildelivery This involves editing the development-specific environment configuration file:

> ruby script/generate mailer UserMailer

The resulting Action Mailer file, like generated Active Record files, is very simple, with

a new class that simply inherits from the relevant base class:

Listing 13.4 app/models/user mailer.rb

class UserMailer < ActionMailer::Base

Listing 13.5 app/models/user mailer.rb

class UserMailer < ActionMailer::Base

Action Mailer uses the instance variables inside reminderto construct a valid email

message Note in particular that elements in the @body hash correspond to instance

variables in the corresponding view; in other words,

@body["user"] = user

gives rise to a variable called@userin the reminder view In the present case, we use the

resulting@uservariable to insert the screen name and password information into the

reminder template:

Listing 13.6 app/views/user mailer/reminder.rhtml

Hello,

Your login information is:

Screen name: <%= @user.screen_name %>

Password: <%= @user.password %>

The RailsSpace team

Since this is just an rhtml file, we can use embedded Ruby as usual

13.1.3 Linking and delivering the reminder

We’ve now laid the foundation for sending email reminders; we just need the

infrastruc-ture to actually send them We’ll start by making a general Email controller to handle

the various email actions on RailsSpace, starting with aremindaction:

> ruby script/generate controller Email remind

exists app/controllers/

Forgot your screen name or password?

<%= link_to "Remind Me!", :controller => "email", :action => "remind" %>

The remind view is a simpleform _ for:

Now set@titlein the Email controller:

Listing 13.9 app/controllers/email controller.rb

class EmailController < ApplicationController

def remind

@title = "Mail me my login information"

end

end

With this, the remind form appears as in Figure 13.2

Finally, we need to fill in theremindaction in the Email controller Previously, in

theloginaction, we used the verbose but convenient method

find_by_screen_name_and_password

Inremind, we use the analogousfind _ by _ emailmethod:

Listing 13.10 app/controllers/email controller.rb

class EmailController < ApplicationController

def remind

@title = "Mail me my login information"

Figure 13.2 The email reminder form.

email = params[:user][:email]

user = User.find_by_email(email)

if user

UserMailer.deliver_reminder(user)

flash[:notice] = "Login information was sent."

redirect_to :action => "index", :controller => "site"

to send the message Action Mailer passes the supplieduservariable to thereminder

method and uses the result to construct a message, which it sends out using the SMTPserver defined in Section 13.1.1

By default, Rails email messages get sent as plain text; see

http://wiki.rubyonrails.org/rails/pages/HowToSendHtmlEmailsWithActionMailer

for instructions on how to send HTML mail using Rails

13.1.4 Testing the reminder

Writing unit and functional tests for mail involves some novel features, but before we

get to that, it’s a good idea to do a test by hand Log in as Foo Bar and change the

email address to (one of) your own After logging out, navigate to the password

re-minder via the login page and fill in your email address The resulting rere-minder should

show up in your inbox within a few seconds; if it doesn’t, double-check the

configu-ration inconfig/environment.rbto make sure that they correspond to your ISP’s

settings

Even if you can’t get your system to send email, automated testing will still probably

work Unit and functional tests don’t depend on the particulars of your configuration,

but rather depend on Rails being able to create UserMailer objects and simulate sending

mail The unit test for the User mailer is fairly straightforward; we create (rather than

deliver) a UserMailer object and then check several of its attributes:2

Listing 13.11 test/unit/user mailer test.rb

require File.dirname( FILE ) + '/ /test_helper'

assert_equal 'do-not-reply@railsspace.com', reminder.from.first

assert_equal "Your login information at RailsSpace.com", reminder.subject

assert_equal @user.email, reminder.to.first

assert_match /Screen name: #{@user.screen_name}/, reminder.body

assert_match /Password: #{@user.password}/, reminder.body

end

2 Feel free to ignore the private functions in this test file; they are generated by Rails and are needed for the

tests, but you don’t have to understand them Lord knows we don’t.

an email message, such assubject, to, anddate, thereby allowing us to test thoseattributes Unfortunately, these are not, in general, the same as the variables created

in Section 13.1.2:fromcomes from@fromandsubjectcomes from@subject, but

tocomes from@recipientsanddate comes from@sent _ on These Action Mailerattributes are poorly documented, but luckily you can guess them for the most part.Let’s go through the assertions intest _ reminder We use

Running the test gives3

1 tests, 5 assertions, 0 failures, 0 errors

3 If you are running Rails 1.2.2 or later, you will get a DEPRECATION WARNING when you run the email tests.

To get rid of the warning, simply change server_settings to smtp_settings in environment.rb

The functional test for the password reminder is a little bit more complicated.

In particular, the setup requires more care In test mode, Rails doesn’t deliver email

messages; instead, it appends the messages to an email delivery object called@emails

This list of emails has to be cleared after each test is run, because otherwise messages

would accumulate, potentially invalidating other tests.4We accomplish this with a call

to thecleararray method in thesetupfunction:

Listing 13.12 test/functional/email controller test.rb

require File.dirname( FILE ) + '/ /test_helper'

require 'email_controller'

# Re-raise errors caught by the controller.

class EmailController; def rescue_action(e) raise e end; end

class EmailControllerTest < Test::Unit::TestCase

This is supposed to happen automatically for tests, but on some systems we’ve found

that setting it explicitly is necessary to avoid actual mail delivery

Since a successful email reminder should add a single message to@emails, the test

checks that a message was “sent” by making sure that the length of the@emailsarray

is 1:

4 With only one test, it doesn’t matter, but presumably we’ll be adding more tests later.

Listing 13.13 test/functional/email controller test.rb

assert_redirected_to :action => "index", :controller => "site"

assert_equal "Login information was sent.", flash[:notice]

1 tests, 4 assertions, 0 failures, 0 errors

13.2 Double-blind email system

In this section, we develop a minimalist email system to allow registered RailsSpace users

to communicate with each other The system will be double-blind, keeping the email

address of both the sender and the recipient private We’ll make an email form thatsubmits to a correspondaction in the Email controller, which will send the actualmessage In the body of the email we’ll include a link back to the same email form sothat it’s easy to reply to the original message.5

13.2.1 Email link

We’ll get the email system started by putting a link to the soon-to-be-written spondaction on each user’s profile Since there is a little bit of logic involved, we’ll wrap

corre-up the details in a partial:

5We really ought to allow users to respond using their regular email account; unfortunately, this would involve

setting up a mail server, which is beyond the scope of this book.

Listing 13.14 app/views/profile/ contact box.rhtml

<% if logged_in? and @user != @logged_in_user %>

<li><%= link_to "Email this user",

:controller => "email", :action => "correspond", :id => @user.screen_name %></li>

</ul>

</div>

<% end %>

We’ve put the link inside a list element tag in anticipation of having more contact

actions later (Section 14.2.1) Since it makes little sense to give users the option to email

themselves, we only show the sidebar box if the profile user is different from the logged-in

user To get this to work, we need to define the@logged _ in _ userinstance variable in

the Profile controller’sshowaction:

Listing 13.15 app/controllers/profile controller.rb

<%= render :partial => 'avatar/sidebar_box' %>

<%= render :partial => 'contact_box' %>

.

.

13.2.2 correspond and the email form

The target of the link in the previous section is thecorrespondaction, which will also

be the target of the email form The form itself will contain the two necessary aspects

of the message, the subject and body In order to do some minimal error-checking oneach message, we’ll make a lightweight Message class based on Active Record, which hasattributes for the message subject and body:

Listing 13.17 app/models/message.rb

class Message < ActiveRecord::Base

attr_accessor :subject, :body

validates_presence_of :subject, :body

validates_length_of :subject, :maximum => DB_STRING_MAX_LENGTH

validates_length_of :body, :maximum => DB_TEXT_MAX_LENGTH

By overriding the initializemethod, we avoid having to create a stub messages

table in the database.6

Since only registered users can send messages, we first protect thecorrespondactionwith a before filter We then use the Message class to create a Message object, which wecan then validate by calling the message’svalid?method:

Listing 13.18 app/controllers/email controller.rb

class EmailController < ApplicationController

be able to use Active Model instead of Active Record in cases such as this one.

flash[:notice] = "Email sent."

We’ve packed a lot of information into the call todeliver _ message, including a

use of our customprofile _ forfunction from Section 9.4.3 (included through the line

include ProfileHelperat the top of the Email controller) We’ll deal with the call

todeliver _ messagein the next section

By creating a new Message object in the correspondaction and including a call

to@message.valid?, we’ve arranged for Rails to generate error messages in the usual

way, which we can put on the corresponding form:

Figure 13.3 The email correspondence page with errors.

This way, if we leave the subject or body blank, we get sensible error messages(Figure 13.3)

13.2.3 Email message

The task remains to complete thecorrespondaction by defining amessagemethod

in the User mailer (so thatUserMailer.deliver _ messageexists), along with a sage.rhtmlview for the message itself

mes-Recall from Section 13.1.2 that

@body["user"] = user

makes a variable@useravailable in thereminder.rhtmlview It turns out that we can

also accomplish this by writing

@body = {"user" => user}

or the even pithier

body user

In this last example, body is a Rails function that sets the @body variable Similar

functions exist for the other mail variables, and together they make for an alternate way

to define methods in Action Mailer classes This means that instead of writing

@subject = 'Your login information at RailsSpace.com'

subject 'Your login information at RailsSpace.com'

body {"user" => user}

recipients user.email

from 'RailsSpace <do-not-reply@railsspace.com>'

The argument to deliver _ message in the correspondaction above is a hash

containing the information needed to construct the message:

In the User mailermessage method, we’ll receive this hash as amailvariable, which

means that we can fill in the message as follows:

Listing 13.20 app/models/user mailer.rb

class UserMailer < ActionMailer::Base

.

.