1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
|
Action Mailer Basics
====================
This guide should provide you with all you need to get started in sending emails from your application, and will also cover how to test your mailers.
== Introduction
Action Mailer allows you to send email from your application using a mailer model and views.
Yes, that is correct, in Rails, emails are used by creating Models that inherit from ActionMailer::Base. They live alongside other models in /app/models BUT they have views just like controllers that appear alongside other views in app/views.
== Sending Emails
Let's say you want to send a welcome email to a user after they signup. Here is how you would go about this:
=== Walkthrough to generating a Mailer
==== 1. Create the mailer:
[source, shell]
-------------------------------------------------------
./script/generate mailer UserMailer
exists app/models/
create app/views/user_mailer
exists test/unit/
create test/fixtures/user_mailer
create app/models/user_mailer.rb
create test/unit/user_mailer_test.rb
-------------------------------------------------------
So we got the model, the fixtures, and the tests all created for us
==== 2. Edit the model:
[source, ruby]
-------------------------------------------------------
class UserMailer < ActionMailer::Base
end
-------------------------------------------------------
Lets add a method called welcome_email, that will send an email to the user's registered email address:
[source, ruby]
-------------------------------------------------------
class UserMailer < ActionMailer::Base
def welcome_email(user)
recipients user.email
from "My Awesome Site Notifications<notifications@example.com>"
subject "Welcome to My Awesome Site"
sent_on Time.now
body {:user => user, :url => "http://example.com/login"}
content_type "text/html"
end
end
-------------------------------------------------------
So what do we have here?
recipients: who the recipients are, put in an array for multiple, ie, @recipients = ["user1@example.com", "user2@example.com"]
from: Who the email will appear to come from in the recipients' mailbox
subject: The subject of the email
sent_on: Timestamp for the email
content_type: The content type, by default is text/plain
How about @body[:user]? Well anything you put in the @body hash will appear in the mailer view (more about mailer views below) as an instance variable ready for you to use, ie, in our example the mailer view will have a @user instance variable available for its consumption.
==== 3. Create the mailer view
Create a file called welcome_email.html.erb in #{RAILS_ROOT}/app/views/user_mailer/ . This will be the template used for the email. This file will be used for html formatted emails. Had we wanted to send text-only emails, the file would have been called welcome_email.txt.erb, and we would have set the content type to text/plain in the mailer model.
The file can look like:
[source, html]
-------------------------------------------------------
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html>
<head>
<meta content='text/html; charset=iso-8859-1' http-equiv='Content-Type' />
</head>
<body>
<h1>Welcome to example.com, <%= @user.first_name %></h1>
<p>
You have successfully signed up to example.com, and your username is: <%= @user.login %>.<br/>
To login to the site, just follow this link: <%= @url %>.
</p>
<p>Thanks for joining and have a great day!</p>
</body>
</html>
-------------------------------------------------------
==== 4. Wire it up so that the system sends the email when a user signs up
There are 3 was to achieve this. One is to send the email from the controller that sends the email, another is to put it in a before_create block in the user model, and the last one is to use an observer on the user model. Whether you use the second or third methods is up to you, but staying away from the first is recommended. Not because it's wrong, but because it keeps your controller clean, and keeps all logic related to the user model within the user model. This way, whichever way a user is created (from a web form, or from an API call, for example), we are guaranteed that the email will be sent.
Edit #{RAILS_ROOT}/config/environment.rb
[source, ruby]
-------------------------------------------------------
# Code that already exists
Rails::Initializer.run do |config|
# Code that already exists
config.active_record.observers = :user_observer
end
-------------------------------------------------------
There was a bit of a debate on where to put observers. I put them in models, but you can create #{RAILS_ROOT}/app/observers if you like, and add that to your load path. Open #{RAILS_ROOT}/config/environment.rb and make it look like:
[source, ruby]
-------------------------------------------------------
# Code that already exists
Rails::Initializer.run do |config|
# Code that already exists
config.load_paths += %W(#{RAILS_ROOT}/app/observers)
config.active_record.observers = :user_observer
end
-------------------------------------------------------
ALMOST THERE :) Now all we need is that danged observer, and we're done:
Create a file called user_observer in #{RAILS_ROOT}/app/models or #{RAILS_ROOT}/app/observers, and make it look like:
[source, ruby]
-------------------------------------------------------
class UserObserver < ActiveRecord::Observer
def after_create(user)
UserMailer.deliver_welcome_email(user)
end
end
-------------------------------------------------------
Notice how we call deliver_welcome_email? Where is that method? Well if you remember, we created a method called welcome_email in UserMailer, right? Well, as part of the "magic" of rails, we deliver the email identified by welcome_email by calling deliver_welcome_email. The next section will go through this in more detail.
That's it! Now whenever your users signup, they will be greeted with a nice welcome email.
=== Action Mailer and dynamic deliver_ methods
So how does Action Mailer understand this deliver_welcome_email call? If you read the documentation (http://api.rubyonrails.org/files/vendor/rails/actionmailer/README.html), you will find this in the "Sending Emails" section:
You never instantiate your mailer class. Rather, your delivery instance
methods are automatically wrapped in class methods that start with the word
deliver_ followed by the name of the mailer method that you would
like to deliver. The signup_notification method defined above is
delivered by invoking Notifier.deliver_signup_notification.
So, how exactly does this work?
In ActionMailer:Base, you will find this:
[source, ruby]
-------------------------------------------------------
def method_missing(method_symbol, *parameters)#:nodoc:
case method_symbol.id2name
when /^create_([_a-z]\w*)/ then new($1, *parameters).mail
when /^deliver_([_a-z]\w*)/ then new($1, *parameters).deliver!
when "new" then nil
else super
end
end
-------------------------------------------------------
Ah, this makes things so much clearer :) so if the method name starts with deliver_ followed by any combination of lowercase letters or underscore, method missing calls new on your mailer class UserMailer in our example above, sending the combination of lower case letters or underscore, along with the parameter. The resulting object is then sent the deliver! method, which well... delivers it.
=== Complete List of ActionMailer user-settable attributes
[width="100%", cols="20%,80%"]
|======================================================
|bcc| Specify the BCC addresses for the message
|body| Define the body of the message. This is either a Hash (in which case it specifies the variables to pass to the template when it is rendered), or a string, in which case it specifies the actual text of the message.
|cc| Specify the CC addresses for the message.
|charset| Specify the charset to use for the message. This defaults to the default_charset specified for ActionMailer::Base.
|content_type| Specify the content type for the message. This defaults to <text/plain in most cases, but can be automatically set in some situations.
|from| Specify the from address for the message.
|reply_to| Specify the address (if different than the "from" address) to direct replies to this message.
|headers| Specify additional headers to be added to the message.
|implicit_parts_order| Specify the order in which parts should be sorted, based on content-type. This defaults to the value for the default_implicit_parts_order.
|mime_version| Defaults to "1.0", but may be explicitly given if needed.
|recipient| The recipient addresses for the message, either as a string (for a single address) or an array (for multiple addresses).
|sent_on| The date on which the message was sent. If not set (the default), the header will be set by the delivery agent.
|subject| Specify the subject of the message.
|template| Specify the template name to use for current message. This is the "base" template name, without the extension or directory, and may be used to have multiple mailer methods share the same template.
|======================================================
=== Mailer Views
Mailer views are located in /app/views/name_of_mailer_class. The specific mailer view is known to the class because it's name is the same as the mailer method. So for example, in our example from above, our mailer view for the welcome_email method will be in /app/views/user_mailer/welcome_email.html.erb for the html version and welcome_email.txt.erb for the plain text version.
To change the default mailer view for your action you do something like:
[source, ruby]
-------------------------------------------------------
class UserMailer < ActionMailer::Base
def welcome_email(user)
recipients user.email
from "My Awesome Site Notifications<notifications@example.com>"
subject "Welcome to My Awesome Site"
sent_on Time.now
body {:user => user, :url => "http://example.com/login"}
content_type "text/html"
# change the default from welcome_email.[html, txt].erb
template "some_other_template" # this will be in app/views/user_mailer/some_other_template.[html, txt].erb
end
end
-------------------------------------------------------
=== Action Mailer Layouts
Just like controller views, you can also have mailer layouts. The layout needs end in _mailer to be automatically recognized by your mailer as a layout. So in our UserMailer example, we need to call our layout user_mailer.[html,txt].erb. In order to use a different file just use:
[source, ruby]
-------------------------------------------------------
class UserMailer < ActionMailer::Base
layout 'awesome' # will use awesome.html.erb as the layout
end
-------------------------------------------------------
Just like with controller views, use yield to render the view inside the layout.
=== Sending multipart emails
Coming soon!
== Receiving Emails
== Using Action Mailer Helpers
== Action Mailer Configuration
The following configuration options are best made in one of the environment files (environment.rb, production.rb, etc...)
[width="100%", cols="2,8a"]
|======================================================
|template_root|Determines the base from which template references will be made.
|logger|the logger is used for generating information on the mailing run if available.
Can be set to nil for no logging. Compatible with both Ruby's own Logger and Log4r loggers.
|smtp_settings|Allows detailed configuration for :smtp delivery method:
[cols="20%,80%"]
!======================================================
!:address !Allows you to use a remote mail server. Just change it from its default "localhost" setting.
!:port !On the off chance that your mail server doesn't run on port 25, you can change it.
!:domain !If you need to specify a HELO domain, you can do it here.
!:user_name !If your mail server requires authentication, set the username in this setting.
!:password !If your mail server requires authentication, set the password in this setting.
!:authentication !If your mail server requires authentication, you need to specify the authentication type here. This is a symbol and one of :plain, :login, :cram_md5.
!======================================================
|sendmail_settings|Allows you to override options for the :sendmail delivery method.
[cols="20%,80%"]
!======================================================
!:location!The location of the sendmail executable. Defaults to /usr/sbin/sendmail.
!:arguments!The command line arguments. Defaults to -i -t.
!======================================================
|raise_delivery_errors|Whether or not errors should be raised if the email fails to be delivered.
|delivery_method|Defines a delivery method. Possible values are :smtp (default), :sendmail, and :test.
|perform_deliveries|Determines whether deliver_* methods are actually carried out. By default they are,
but this can be turned off to help functional testing.
|deliveries|Keeps an array of all the emails sent out through the Action Mailer with delivery_method :test. Most useful
for unit and functional testing.
|default_charset|The default charset used for the body and to encode the subject. Defaults to UTF-8. You can also
pick a different charset from inside a method with charset.
|default_content_type|The default content type used for the main part of the message. Defaults to "text/plain". You
can also pick a different content type from inside a method with content_type.
|default_mime_version|The default mime version used for the message. Defaults to 1.0. You
can also pick a different value from inside a method with mime_version.
|default_implicit_parts_order|When a message is built implicitly (i.e. multiple parts are assembled from templates
which specify the content type in their filenames) this variable controls how the parts are ordered. Defaults to
["text/html", "text/enriched", "text/plain"]. Items that appear first in the array have higher priority in the mail client
and appear last in the mime encoded message. You can also pick a different order from inside a method with
implicit_parts_order.
|======================================================
=== Example Action Mailer Configuration
An example would be:
[source, ruby]
-------------------------------------------------------
ActionMailer::Base.delivery_method = :sendmail
ActionMailer::Base.sendmail_settings = {
:location => '/usr/sbin/sendmail',
:arguments => '-i -t'
}
ActionMailer::Base.perform_deliveries = true
ActionMailer::Base.raise_delivery_errors = true
ActionMailer::Base.default_charset = "iso-8859-1"
-------------------------------------------------------
=== Action Mailer Configuration for GMail
Instructions copied from http://http://www.fromjavatoruby.com/2008/11/actionmailer-with-gmail-must-issue.html
First you must install the action_mailer_tls plugin from http://code.openrain.com/rails/action_mailer_tls/, then all you have to do is configure action mailer.
[source, ruby]
-------------------------------------------------------
ActionMailer::Base.smtp_settings = {
:address => "smtp.gmail.com",
:port => 587,
:domain => "domain.com",
:user_name => "user@domain.com",
:password => "password",
:authentication => :plain
}
-------------------------------------------------------
=== Configure Action Mailer to recognize HAML templates
In environment.rb, add the following line:
[source, ruby]
-------------------------------------------------------
ActionMailer::Base.register_template_extension('haml')
-------------------------------------------------------
== Mailer Testing
Testing mailers involves 2 things. One is that the mail was queued and the other that the body contains what we expect it to contain. With that in mind, we could test our example mailer from above like so:
[source, ruby]
-------------------------------------------------------
class UserMailerTest < ActionMailer::TestCase
tests UserMailer
def test_welcome_email
user = users(:some_user_in_your_fixtures)
# Send the email, then test that it got queued
email = UserMailer.deliver_welcome_email(user)
assert !ActionMailer::Base.deliveries.empty?
# Test the body of the sent email contains what we expect it to
assert_equal [@user.email], email.to
assert_equal "Welcome to My Awesome Site", email.subject
assert email.body =~ /Welcome to example.com, #{user.first_name}/
end
end
-------------------------------------------------------
What have we done? Well, we sent the email and stored the returned object in the email variable. We then ensured that it was sent (the first assert), then, in the second batch of assertion, we ensure that the email does indeed contain the values that we expect.
== Epilogue
This guide presented how to create a mailer and how to test it. In reality, you may find that writing your tests before you actually write your code to be a rewarding experience. It may take some time to get used to TDD (Test Driven Development), but coding this way achieves two major benefits. Firstly, you know that the code does indeed work, because the tests fail (because there's no code), then they pass, because the code that satisfies the tests was written. Secondly, when you start with the tests, you don't have to make time AFTER you write the code, to write the tests, then never get around to it. The tests are already there and testing has now become part of your coding regimen.
|
