class UserMailer < ActionMailer::Base end
From 9f030acf22696a476578e9ccde9984fa1b86f02c Mon Sep 17 00:00:00 2001
From: Xavier Noria This guide should provide you with all you need to get started in sending and receiving emails from/to your application, and many internals of the ActionMailer class. It will also cover how to test your mailers. This guide should provide you with all you need to get started in sending and receiving emails from/to your application, and many internals of Action Mailer. It will also cover how to test your mailers. 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. Let’s say you want to send a welcome email to a user after they signup. Here is how you would go about this: Lets add a method called welcome_email, that will send an email to the user’s registered email address: Lets add a method called welcome_email, that will send an email to the user’s registered email address: recipients who the recipients are, put in an array for multiple, ie, @recipients = ["user1@example.com", "user2@example.com"] The recipients of the email. It can be a string or, if there are multiple recipients, an array of strings from 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. The keys of the hash passed to body become instance variables in the view. Thus, in our example the mailer view will have a @user and a @url instance variables available. The file can look like: There are 3 ways 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. There are three ways 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 callback 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. Let’s see how we would go about wiring it up using an observer: In config/environment.rb: In config/environment.rb: There was a bit of a debate on where to put observers. Some people put them in app/models, but a cleaner method may be to create an app/observers folder to store all observers, and add that to your load path. Open config/environment.rb and make it look like: ALMOST THERE :) Now all we need is that danged observer, and we’re done:
-Create a file called user_observer in app/models or app/observers depending on where you stored it, and make it look like: Now create a file called user_observer in app/models or app/observers depending on where you stored it, and make it look like: 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. 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. 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.
-
Action Mailer Basics
1. Introduction
2. Sending Emails
2.1. Walkthrough to generating a Mailer
+2.1. Walkthrough to generating a mailer
2.1.1. Create the mailer:
class UserMailer < ActionMailer::Base
end
-
+
@@ -172,7 +172,7 @@ cellspacing="0" cellpadding="4">
2.1.3. Create the mailer view
<!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' />
+ <meta content="text/html; charset=UTF-8" http-equiv="Content-Type" />
</head>
<body>
- <h1>Welcome to example.com, <%= @user.first_name %></h1>
+ <h1>Welcome to example.com, <%=h @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 %>.
+ You have successfully signed up to example.com, and your username is: <%=h @user.login %>.<br/>
+ To login to the site, just follow this link: <%=h @url %>.
</p>
<p>Thanks for joining and have a great day!</p>
</body>
</html>
2.1.4. Wire it up so that the system sends the email when a user signs up
-# Code that already exists
Rails::Initializer.run do |config|
-
# Code that already exists
-
config.active_record.observers = :user_observer
-
end
2.2. Action Mailer and dynamic deliver_ methods
+2.2. Action Mailer and dynamic deliver_* methods
So, how exactly does this work?
In ActionMailer:Base, you will find this:
In ActionMailer::Base, you will find this:
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.
Hence, 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 parameters. The resulting object is then sent the deliver! method, which well... delivers it.
WEBrick isn’t your only option for serving Rails. We’ll get to that in a later section. [XXX: which section] |
Here we’ll flex our server command, which without any prodding of any kind will run our new shiny Rails app:
Without any prodding of any kind, server will run our new shiny Rails app:
$ mkdir gitapp +$ cd gitapp +$ git init +Initialized empty Git repository in .git/ +$ rails . --git --database=postgresql + exists + create app/controllers + create app/helpers +... +... + create tmp/cache + create tmp/pids + create Rakefile +add 'Rakefile' + create README +add 'README' + create app/controllers/application.rb +add 'app/controllers/application.rb' + create app/helpers/application_helper.rb +... + create log/test.log +add 'log/test.log'
We had to create the gitapp directory and initialize an empty git repository before Rails would add files it created to our repository. Let’s see what it put in our database configuration:
$ cat config/database.yml +# PostgreSQL. Versions 7.4 and 8.x are supported. +# +# Install the ruby-postgres driver: +# gem install ruby-postgres +# On Mac OS X: +# gem install ruby-postgres -- --include=/usr/local/pgsql +# On Windows: +# gem install ruby-postgres +# Choose the win32 build. +# Install PostgreSQL and put its /bin directory on your path. +development: + adapter: postgresql + encoding: unicode + database: gitapp_development + pool: 5 + username: gitapp + password: +... +...
It also generated some lines in our database.yml configuration corresponding to our choice of PostgreSQL for database. The only catch with using the SCM options is that you have to make your application’s directory first, then initialize your SCM, then you can run the rails command to generate the basis of your app.
Of course, in production environment you would need much robust code, and could use a plugin such as Iaian Hecker’s http_accept_language.
Of course, in production environment you would need much robust code, and could use a plugin such as Iaian Hecker’s http_accept_language or even Rack middleware such as Ryan Tomayko’s locale.
Another way of choosing the locale from client’s information would be to use a database for mapping client IP to region, such as GeoIP Lite Country. The mechanics of the code would be very similar to the code above — you would need to query database for user’s IP, and lookup your preffered locale for the country/region/city returned.
You may use YAML (.yml) or plain Ruby (.rb) files for storing your translations in SimpleStore. YAML is the preffered option among Rails developers, has one big disadvantage, though. YAML is very sensitive to whitespace and special characters, so the application may not load your dictionary properly. Ruby files will crash your application on first request, so you may easily find what’s wrong. (If you encounter any "weird issues" with YAML dictionaries, try putting the relevant portion of your dictionary into Ruby file.)
OK! Now let’s add a timestamp to the view, so we can demo the date/time localization feature as well. To localize the time format you pass the Time object to I18n.l or (preferably) use Rails' #l helper. You can pick a format by passing the :format option — by default the :default format is used.