27.02.2013 Views

Rails%203%20In%20Action

Rails%203%20In%20Action

Rails%203%20In%20Action

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

322 CHAPTER 12 Sending email<br />

Great to see everything still passing! You’ve added email ticket notifications to your<br />

application, so you should now make a commit saying just that and push it:<br />

git add .<br />

git commit -m "Add email ticket notifications"<br />

git push<br />

Now that you’ve got your application sending plain-text emails, let’s bring it into the<br />

21st century by getting it to send out HTML emails as well.<br />

12.1.6 Delivering HTML emails<br />

Emails can have multiple parts associated with them, which allows emails to have<br />

attachments and different content types. For instance, some email applications don’t<br />

read HTML emails and will fall back to the text version of the template instead. More<br />

modern applications will render the HTML, presenting a prettier, formatted email.<br />

With HTML, you’re able to style your emails to include elements such as images,<br />

and HTML tags such as the a tag. By doing this, you can provide a much better-looking<br />

email than the plain-text version, as shown in figure 12.2.<br />

You need to make only a couple of small changes to this email, such as the image at<br />

the top and the link that now reads View This Ticket Online Here. You could do<br />

more, but this will suit your purposes for now.<br />

Some email clients don’t support receiving HTML-only emails. Thankfully, Action<br />

Mailer has a solution to this problem. When you send your comment_updated email, it<br />

will arrive all in the same message, but that message will contain multiple parts. The<br />

first part of the email will be the text template that you set up earlier, and the second<br />

part will be the new HTML version that you’ll code up in just a tad. Modern email clients<br />

are smart enough to detect an email such as this, and if they’re capable of rendering<br />

the HTML version they’ll do so; if not they will fall back to the plain-text<br />

variant.<br />

To test that this works, you add another couple of steps right after the check of the<br />

email body in the scenario inside features/ticket_notifications.feature. These steps will<br />

check that you receive an email that contains two parts, with one of them having the<br />

content type of text/plain and the other of text/html:<br />

Figure 12.2<br />

A better-looking email

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!