Class Merb::MailController
In: lib/merb-mailer/mail_controller.rb
Parent: AbstractController

Sending mail from a controller involves three steps:

  • Set mail settings in merb_init.rb (Not shown here...see the Mailer docs).
  • Create a MailController subclass with actions and templates.
  • Call the MailController from another Controller via the send_mail method.

First, create a file in app/mailers that subclasses Merb::MailController. The actions in this controller will do nothing but render mail.

  # app/mailers/article_mailer.rb
  class ArticleMailer < Merb::MailController

    def notify
      @user = params[:user]
      render_mail
    end

  end

You also can access the params hash for values passed with the Controller.send_mail method. See also the documentation for render_mail to see all the ways it can be called.

Create a template in a subdirectory of app/mailers/views that corresponds to the controller and action name. Put plain text and ERB tags here:

  # app/mailers/views/article_mailer/notify.text.erb
  Hey, <%= @user.name %>,

  We're running a sale on dog bones!

Finally, call the Controller.send_mail method from a standard Merb controller.

  class Articles < Application

    def index
      @user = User.find_by_name('louie')

      send_mail(ArticleMailer, :notify, {
        :from => "me@example.com",
        :to => "louie@example.com",
        :subject => "Sale on Dog Bones!"
      }, { :user => @user })
      render
    end

  end

Note: If you don‘t pass a fourth argument to Controller.send_mail, the controller‘s params will be sent to the MailController subclass as params. However, you can explicitly send a hash of objects that will populate the params hash instead. In either case, you must set instance variables in the MailController‘s actions if you want to use them in the MailController‘s views.

The MailController class is very powerful. You can:

  • Send multipart email with a single call to render_mail.
  • Attach files.
  • Render layouts and other templates.
  • Use any template engine supported by Merb.

Methods

Attributes

base_controller  [R] 
mail  [RW] 
mailer  [RW] 
params  [RW] 

Public Class methods

A convenience method that creates a blank copy of the MailController and runs dispatch_and_deliver on it.

Parameters

method<~to_s>:The method name to dispatch to.
mail_params<Hash>:Parameters to send to MailFactory.
send_params<Hash>:Configuration parameters for the MailController.

Sets the template root to the default mailer view directory.

Parameters

klass<Class>:The Merb::MailController inheriting from the base class.

Parameters

params<Hash>:Configuration parameters for the MailController.
controller<Merb::Controller>:The base controller.

Returns

Array[Class]:Classes that inherit from Merb::MailController.

Public Instance methods

The location to look for a template and mime-type. This is overridden from AbstractController, which defines a version of this that does not involve mime-types.

Parameters

template<String>:The absolute path to a template - without mime and template extension. The mime-type extension is optional - it will be appended from the current content type if it hasn‘t been added already.
type<~to_s>:The mime-type of the template that will be rendered. Defaults to nil.

@public

Parameters

action<~to_s>:The name of the action that will be rendered.
type<~to_s>:The mime-type of the template that will be rendered. Defaults to nil.
controller<~to_s>:The name of the controller that will be rendered. Defaults to controller_name.

Returns

String:The template location, i.e. ":controller/:action.:type".

Mimic the behavior of absolute_url in AbstractController but use @base_controller.request

Attaches a file or multiple files to an email. You call this from a method in your MailController (including a before filter).

Parameters

file_or_files<File, Array[File]>:File(s) to attach.

filename<String>::

type<~to_s>:The attachment MIME type. If left out, it will be determined from file_or_files.
headers<String, Array>:Additional attachment headers.

Examples

  attach File.open("foo")
  attach [File.open("foo"), File.open("bar")]

If you are passing an array of files, you should use an array of the allowed parameters:

  attach [[File.open("foo"), "bar", "text/html"], [File.open("baz"),
    "bat", "text/css"]

 which would attach two files ("foo" and "baz" in the filesystem) as

"bar" and "bat" respectively. It would also set the mime-type as "text/html" and "text/css" respectively.

Parameters

method<~to_s>:The method name to dispatch to.
mail_params<Hash>:Parameters to send to MailFactory (see below).

Options (mail_params)

MailFactory recognizes the following parameters:

  • :to
  • :from
  • :replyto
  • :subject
  • :body
  • :cc

Other parameters passed in will be interpreted as email headers, with underscores converted to dashes.

Override filters halted to return nothing.

relative_url(name, *args)

Alias for url

Allows you to render various types of things into the text and HTML parts of an email If you include just text, the email will be sent as plain-text. If you include HTML, the email will be sent as a multi-part email.

Parameters

options<~to_s, Hash>:Options for rendering the email or an action name. See examples below for usage.

Examples

There are a lot of ways to use render_mail, but it works similarly to the default Merb render method.

First of all, you‘ll need to store email files in your app/mailers/views directory. They should be under a directory that matches the name of your mailer (e.g. TestMailer‘s views would be stored under test_mailer).

The files themselves should be named action_name.mime_type.extension. For example, an erb template that should be the HTML part of the email, and rendered from the "foo" action would be named foo.html.erb.

The only mime-types currently supported are "html" and "text", which correspond to text/html and text/plain respectively. All template systems supported by your app are available to MailController, and the extensions are the same as they are throughout the rest of Merb.

render_mail can take any of the following option patterns:

  render_mail

will attempt to render the current action. If the current action is "foo", this is identical to render_mail :foo.

  render_mail :foo

checks for foo.html.ext and foo.text.ext and applies them as appropriate.

  render_mail :action => {:html => :foo, :text => :bar}

checks for foo.html.ext and bar.text.ext in the view directory of the current controller and adds them to the mail object if found

  render_mail :template => {:html => "foo/bar", :text => "foo/baz"}

checks for bar.html.ext and baz.text.ext in the foo directory and adds them to the mail object if found.

  render_mail :html => :foo, :text => :bar

the same as render_mail :action => {html => :foo, :text => :bar }

  render_mail :html => "FOO", :text => "BAR"

adds the text "FOO" as the html part of the email and the text "BAR" as the text part of the email. The difference between the last two examples is that symbols represent actions to render, while string represent the literal text to render. Note that you can use regular render methods instead of literal strings here, like:

  render_mail :html => render(:action => :foo)

but you‘re probably better off just using render_mail :action at that point.

You can also mix and match:

  render_mail :action => {:html => :foo}, :text => "BAR"

which would be identical to:

  render_mail :html => :foo, :text => "BAR"

Mimic the behavior of absolute_url in AbstractController but use @base_controller.request

Protected Instance methods

Returns

Hash:The route from base controller.

[Validate]