merb

merbkicking mvc into high gear

Booth 501

I work for Engine Yard. They help fund projects like Merb and Rubinius, and allow me to spend time making DataMapper better. They rock.

what’s merb?

web framework

emphasizes efficiency and hackability

Instead of emphasizing a complete, monolithic framework with everything built in for the 80-20 case, Merb emphasizes making it easy to build what you need. That doesn’t mean we don’t want to make it easy to get started. Merb’s defaults provide the get-up-and-running feel that you get from more monolithic frameworks.

modular

improved api

We try to learn from other frameworks in Ruby and in the programming world at large. When we find something we like, we use it. When we find something we think we can make easier to interact with, we do that.

give you as much headroom as possible

Our goal is to maintain as small a footprint as possible to give your app more system resources to use.

no &:sym in merb

For instance, we don’t use Symbol#to_proc inside Merb, which is a convenience but dramatically slows down operations that use it.

slowdowns are a bug

Slowdowns are not unfortunate. They are a bug. If you notice that a commit to Merb makes it slower, file a ticket on LightHouse. We will take it seriously.

simplicity ftw

MOTTO: no code is faster

than no code

things you hear

developer time is expensive

servers are cheap

ergo: efficiency doesn’t matter

you can always throw more hardware at it

And we at EY are happy to sell you hardware.

but what if you could have both?

What if we didn’t have to choose between developer efficiency and machine efficiency?

?

Would that be the holy grail?

no, that’s merb.

merb 0.9

based on rack

Rack is based on Python’s WSGY, which allows a web framework like Merb to interact with a bunch of web servers (like Mongrel, Thin, Ebb, Webrick, CGI, FastCGI)

class ApiHandler def initialize(app) @app = app end

def call(env) ... endend

use ApiHandlerrun Merb::Rack::Application.new

Here’s an example Rack handler.

def call(env) request = Merb::Request.new if request.path =~ %r{/api/(.*)} [200, {“Content-Type” => “text/json”}, Api.get_json($1)] else @app.call(env) endend

Here’s what the call method looks like. You return a tuple of [status_code, headers, body].

router

Merb has a kick-ass router.

Merb::Router.prepare do |r| r.resources :posts do |post| post.resources :comments endend

We support simple stuff, like resources or even nested resources.

Merb::Router.prepare do |r| r.match(%r{/login/(.*)}, :user_agent => /MSIE/). to(:controller => “account”, :action => “login”, :id => “[1]”end

But we also support regexen.

Merb::Router.prepare do |r| r.match(%r{/login/(.*)}, :user_agent => /MSIE/). to(:controller => “account”, :action => “login”, :id => “[1]”end

checks request.user_agent

Or any part of the Request object.

Merb::Router.prepare do |r| r.match(%r{/login/(.*)}, :user_agent => /MSIE/). to(:controller => “account”, :action => “login”, :id => “[1]”end

You can use any capture from your regex in #to hashes via “[capture_number]”

Merb::Router.prepare do |r| r.match(%r{/login/(.*)}, :method => “post”). to(:controller => “account”, :action => “login”, :id => “[1]”end

Here’s another example of using the Request object.

Merb::Router.prepare do |r| r.match(%r{/login/(.*)}, :protocol => “http://”). to(:controller => “account”, :action => “login”, :id => “[1]”end

accepts header,meet provides

Your client tells Merb what it can accept. You tell Merb what a controller can provide.

class Post < Application provides :json, :yaml

def show @post = Post[params[:id]] display @post endend

Here, you tell Merb to provide JSON and YAML. Then, you tell it to serialize the @post object into the appropriate form depending on what the client requested.

display flowdisplay @foo

get content_type

XML

Look for foo.xml.* yes render

Here’s how Merb determines what to render given a specific parameter to display. This workflow assumes the client asked for XML.

display flowdisplay @foo

get content_type

XML

Look for foo.xml.*

@foo.to_xmlno?

display flowdisplay @foo

get content_type

XML

Look for foo.xml.*

@foo.to_xml

default mimes

In order to make this work simply and seamlessly, we need Merb to know about a set of default mime types. Here’s the list.

Merb.add_mime_type(:all, nil, %w[*/*])

Merb.add_mime_type(:yaml, :to_yaml, %w[application/x-yaml text/yaml])

Merb.add_mime_type(:text, :to_text, %w[text/plain])

Merb.add_mime_type(:html, :to_html, %w[text/html application/xhtml+xml application/html])

The first parameter is the internal name for the mime used by Merb. It is also the extension to use for a URL if you want that mime to be used (http://foo.com/index.json will use the :json type).

Merb.add_mime_type(:xml, :to_xml, %w[application/xml text/xml application/x-xml], :Encoding => "UTF-8")

Merb.add_mime_type(:js, :to_json, %w[text/javascript application/javascript application/x-javascript])

Merb.add_mime_type(:json, :to_json, %w[application/json text/x-json])

The second parameter is an Array of mime types from the Accept header that will match the mime. The first item in the list is the mime-type that will be returned to the client.

class Post < Application provides :json, :yaml, :xml

def show @post = Post[params[:id]] display @post endend

Here’s the example again.

class Post < Application provides :json, :yaml, :xml

def show(id) @post = Post[id] display @post endend

merb-action-args

We can use the merb-action-args to simplify our controllers.

a benefit of modularity

Let’s take a look at an simple benefit of Merb’s modularity.

class Mail < Merb::Mailer before :shared_behavior

def index render_mail endend

Mailers look the same as controllers.

class Mail < Merb::Mailer before :shared_behavior

def index render_mail :foo endend

You can pass them a symbol, which will use a different template.

class Mail < Merb::Mailer before :shared_behavior

def index render_mail :html => :foo, :text => :bar endend

You can also use special templates for html and text, without any fancy methods.

class Mail < Merb::Mailer before :shared_behavior

def index attach File.open(“/foo/bar”) render_mail :html => :foo, :text => :bar endend

You can attach a file, which will automatically figure out the mime and use it.

class Mail < Merb::Mailer before :shared_behavior layout :mailers

def index attach File.open(“/foo/bar”) render_mail :html => :foo, :text => :bar endend

You can use layouts, just like regular controllers.

send_mail Mail, :index, {:to => “wycats@gmail.com”}

You call mailers in your controllers like this.

class Mail < Merb::Mailer before :shared_behavior layout :mailers

def index attach File.open(“/foo/bar”) render_mail :html => :foo, :text => :bar endend

class Mail < Merb::Mailer before :shared_behavior layout :mailers

def index mail.to = [“wycats@gmail.com”] attach File.open(“/foo/bar”) render_mail :html => :foo, :text => :bar endend

You also have access to the raw mailer object (a MailFactory object).

testing

What about testing?

controllers are plain old ruby objects

You can test Merb objects like real Ruby objects.

instantiated with new

actions are methods

they return data

describe MyController do it “returns some json” do @mock = fake_request( :accept => “application/json”) c = MyController.new(@mock) c._dispatch(:index).should == {:foo => “bar”}.to_json endend

This is the raw way of doing testing. You probably wouldn’t do this, and it uses a private method (_dispatch).

describe MyController do it “returns some json” do dispatch_to( MyController, :index, {:foo => :bar}, {:accept => “application/json”} ) @controller.body.should == {:foo => :bar}.to_json endend

You can use Merb’s helpers as well.

describe MyController do it “returns some json” do dispatch_to( MyController, :index, {:foo => :bar}, {:accept => “application/json”} ) @controller.body.should == {:foo => :bar}.to_json endend

controller

describe MyController do it “returns some json” do dispatch_to( MyController, :index, {:foo => :bar}, {:accept => “application/json”} ) @controller.body.should == {:foo => :bar}.to_json endend

action

describe MyController do it “returns some json” do dispatch_to( MyController, :index, {:foo => :bar}, {:accept => “application/json”} ) @controller.body.should == {:foo => :bar}.to_json endend

params

describe MyController do it “returns some json” do dispatch_to( MyController, :index, {:foo => :bar}, {:accept => “application/json”} ) @controller.body.should == {:foo => :bar}.to_json endend

request environment

getting started

sake (edge)

The preferred way to keep up with Merb now is to use the sake tasks.

sudo gem install sake

sake -i http://merbivore.com/merb-dev.sake

mkdir ~/merb_sources

cd ~/merb_sources

sake merb:clone

sake merb:install

sake merb:upate # later

Do this.

gem install merb

You can also get the latest released gems from Rubyforge.

merb-gen app my_app

This is the equivalent of rails my_app.

init.rb

You’ll probably want to customize init.rb.

use_orm :datamapper

use_test :rspec

dependency “merb_more” # or what you need

... other dependencies ...

Merb::BootLoader.before_app_loads do DataMapper.setup(:salesforce, ...)end

Use before_app_loads for things that need to know about the structure of the framework (where your controllers/models/etc. are). The dependency method automatically handles the appropriate time to load the plugin.

merb != Rails

We’ve had a lot of back-and-forth about things that are not the same between Merb and Rails. Here’s a list of things that you should be aware of when coming from a Rails background.

before vs. before_filter

Controllers use before :foo instead of before_filter :foo.

provides vs. respond_to

As shown above, we use a completely different API than Rails does for deciding what mime-type to return.

:except vs. :exclude

We use before :foo, :except => :bar instead of before_filter :foo, :exclude => :bar

logger vs. merb.logger

We do not have a Kernel method for our logger. You get access to our logger by doing Merb.logger.info!

fooscontroller vs. foos

Since we don’t use const_missing to figure out where to load things, there are no naming requirements for any class. All classes are loaded at boot-time.

url_for vs. url

We do url(:resource, @resource) instead of url_for_resource(@resource).

css_include_tag :foo, :bundle => :basevs.

stylesheet_link_tag :foo, :bundle => :base

We use css_include_tag instead of stylesheet_link_tag. We also use js_include_tag for consistency.

mailers

As shown above, our mailers are different (and much cooler).

no rjs

We don’t use RJS. We recommend using Unobtrusive JavaScript techniques and a merb_jquery plugin along these lines is available.

mandatory render

Merb actions return strings. This provides massive additional flexibility when using actions from other methods. Our render method just returns a string, and is thus required at the end of actions.

render returns string

render :foo

render :foo renders a template, but ...

render “foo”

render “foo” renders the string wrapped in the layout. Just “foo” renders the string itself.

render_json

render :json => :... becomes render_json :...

no render :json => ...

it’s considered a bug if

There’s a bunch of notions that are typically not considered bugs, but which we do.

★ symbol#to_proc

★ alias_method_chain

★ merb gets slower

★ private api use

★ public api change*

★ non-documented

★ params

★ options keys

★ returns

★ yields

it’s considered a bug

*without deprecation period and notice in public API changelog

alias_method_chain is ok in your app code, but it’s a bug if we use it in Merb.

thank you.

any questions?

Feel free to comment on this blog post or email me at wycats@gmail.com.

</railsconf>