Upload
yehuda-katz
View
13.730
Download
1
Tags:
Embed Size (px)
DESCRIPTION
All about Merb
Citation preview
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 => “[email protected]”}
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 = [“[email protected]”] 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 [email protected].
</railsconf>