mirror of
https://github.com/sinatra/sinatra
synced 2023-03-27 23:18:01 -04:00
Classy web-development dressed in a DSL (official / canonical repo)
0e367a5241
This uses the hanna command shipped with the hanna gem. The preferred method of using is to require 'hanna/rdoctask' in your Rakefile but this caused various gem depency errors (blame Hoe, rdoc 2.0, Echoe, and rubyforge). You have to install mislav's hanna gem from github: $ sudo gem install mislav-hanna --source=http://gems.github.com Run the doc task to generate rdoc under doc/api: $ rake doc See mislav's repo for more info on template usage: http://github.com/mislav/hanna See the HAML docs for an example of the hanna template in action: http://haml.hamptoncatlin.com/docs/rdoc |
||
---|---|---|
images | ||
lib | ||
test | ||
vendor | ||
.gitignore | ||
.gitmodules | ||
LICENSE | ||
Rakefile | ||
README.rdoc | ||
sinatra.gemspec |
= Sinatra Sinatra is a DSL for quickly creating web-applications in Ruby with minimal effort. == Sample App # myapp.rb require 'rubygems' require 'sinatra' get '/' do 'Hello world!' end Run with <tt>ruby myapp.rb</tt> and view at <tt>http://localhost:4567</tt> == HTTP Methods get '/' do .. show things .. end post '/' do .. create something .. end put '/' do .. update something .. end delete '/' do .. annihilate something .. end head '/' do end NOTE: <tt>put</tt> and <tt>delete</tt> are also triggered when a <tt>_method</tt> parameter is set to PUT or DELETE and the HTTP request method is POST == Routes Routes are matched based on the order of declaration. The first route that matches the request is invoked. Simple: get '/hi' do ... end Named parameters: get '/:name' do # matches /sinatra and the like and sets params[:name] end Splat parameters: get '/say/*/to/*' do # matches /say/hello/to/world params["splat"] # => ["hello", "world"] end get '/download/*.*' do # matches /download/path/to/file.xml params["splat"] # => ["path/to/file", "xml"] end User agent matching: get '/foo', :agent => /Songbird (\d\.\d)[\d\/]*?/ do "You're using Songbird version #{params[:agent][0]}" end get '/foo' do # matches non-songbird browsers end = Static files Put all of your static content in the ./public directory root \ public If a file exists that maps to the REQUEST_PATH then it is served and the request ends. Otherwise, Sinatra will look for an event that matches the path. == Views Views are searched for in a "views" directory in the same location as your main application. === Haml Templates get '/' do haml :index end Renders <tt>./views/index.haml</tt>. === Erb get '/' do erb :index end Renders <tt>./views/index.erb</tt> === Builder See Sinatra::Builder === Sass get '/stylesheet.css' do content_type 'text/css', :charset => 'utf-8' sass :stylesheet end Renders <tt>./views/stylesheet.sass</tt>. === Inline Templates get '/' do haml '%div.title Hello World' end Renders the inlined template string. === Accessing Variables Templates are evaluated within the Sinatra::EventContext instance used to evaluate event blocks. Instance variables set in event blocks can be accessed direcly in views: get '/:id' do @foo = Foo.find(params[:id]) haml '%h1== @foo.name' end Or, specify an explicit Hash of local variables: get '/:id' do foo = Foo.find(params[:id]) haml '%h1== foo.name', :locals => { :foo => foo } end This is typically used when rendering templates as partials from within other templates. === In-file Templates Templates may be defined at the end of the source file: get '/' do haml :index end use_in_file_templates! __END__ @@ layout X = yield X @@ index %div.title Hello world!!!!! It's also possible to define named templates using the template :layout do "X\n=yield\nX" end template :index do '%div.title Hello World!' end get '/' do haml :index end == Helpers The top-level <tt>helpers</tt> method takes a block and extends all EventContext instances with the methods defined: helpers do def bar(name) "#{name}bar" end end get '/:name' do bar(params[:name]) end == Filters These are run in Sinatra::EventContext before every event. before do .. this code will run before each event .. end == Halt! To immediately stop a request during a before filter or event use: throw :halt Set the body to the result of a helper method throw :halt, :helper_method Set the body to the result of a helper method after sending it parameters from the local scope throw :halt, [:helper_method, foo, bar] Set the body to a simple string throw :halt, 'this will be the body' Set status then the body throw :halt, [401, 'go away!'] Set the status then call a helper method with params from local scope throw :halt, [401, [:helper_method, foo, bar]] Run a proc inside the Sinatra::EventContext instance and set the body to the result throw :halt, lambda { puts 'In a proc!'; 'I just wrote to $stdout!' } Create you own to_result class MyResultObject def to_result(event_context, *args) event_context.body = 'This will be the body! end end get '/' do throw :halt, MyResultObject.new end Get the gist? If you want more fun with this then checkout <tt>to_result</tt> on Array, Symbol, Fixnum, NilClass. == Configuration and Reloading Sinatra supports multiple environments and re-loading. Re-loading happens on every request when in :development. Wrap your configurations in <tt>configure</tt> (i.e. Database connections, Constants, etc.) to protect them from re-loading and to only work in certain environments. All environments: configure do end Production configure :production do end Two at a time: configure :production, :test do end This is also really nifty for error handling. = Error handling == Not Found Remember: These are run inside the Sinatra::EventContext which means you get all the goodies is has to offer (i.e. haml, erb, :halt, etc.) Whenever NotFound is raised this will be called not_found do 'This is nowhere to be found' end == Error By default +error+ will catch Sinatra::ServerError Sinatra will pass you the error via the 'sinatra.error' in request.env error do 'Sorry there was a nasty error - ' + request.env['sinatra.error'].name end Custom error mapping: error MyCustomError do 'So what happened was...' + request.env['sinatra.error'].message end then if this happens: get '/' do raise MyCustomError, 'something bad' end you gets this: So what happened was... something bad one guess what this does ;) not_found do 'I have no clue what you're looking for' end Because Sinatra gives you a default <tt>not_found</tt> and <tt>error</tt> do :production that are secure. If you want to customize only for :production but want to keep the friendly helper screens for :development then do this: configure :production do not_found do "We're so sorry, but we don't what this is" end error do "Something really nasty happened. We're on it!" end end == Mime types When using send_file or static files you may have mime types Sinatra doesn't understand. Use +mime+ in those cases. mime :foo, 'text/foo' == Rack Middleware Sinatra rides on Rack[http://rack.rubyforge.org/], a minimal standard interface for Ruby web frameworks. One of Rack's most interesting capabilities for application developers is support for "middleware" -- components that sit between the server and your application monitoring and/or manipulating the HTTP request/response to provide various types of common functionality. What's more, middleware is portable between web frameworks, so middleware components developed under, e.g., Merb, can be used with Sinatra and vice versa. Sinatra makes building Rack middleware pipelines a cinch via a top-level +use+ method: require 'sinatra' require 'my_custom_middleware' use Rack::Lint use MyCustomMiddleware get '/hello' do 'Hello World' end The semantics of +use+ are identical to those defined for the Rack::Builder[http://rack.rubyforge.org/doc/classes/Rack/Builder.html] DSL (most frequently used from rackup files). For example, the +use+ method accepts multiple/variable args as well as blocks: use Rack::Auth::Basic do |username, password| username == 'admin' && password == 'secret' end Rack is distributed with a variety of standard middleware for logging, debugging, URL routing, authentication, and session handling. Sinatra uses many of of these components automatically based on configuration so you typically don't have to +use+ them explicitly. == Testing === Methods get_it path, params get_it path, params.merge(:env => { 'HTTP_HOST' => 'www.sinatrarb.com' }) or get_it path, params.merge(:env => { :host => 'www.sinatrarb.com' }) RESTful: post_it '/foo', '<myxml></myxml>', 'HTTP_ACCEPT' => 'application/xml' also works with: get_it, post_it, put_it, delete_it, head_it === Test/Unit require 'my_sinatra_app' require 'sinatra/test/unit' class MyAppTest < Test::Unit::TestCase def test_my_default get_it '/' assert_equal 'My Default Page!', @response.body end def test_with_agent get_it '/', :agent => 'Songbird' assert_equal 'You're in Songbird!', @response.body end ... end === Specs require 'my_sinatra_app' require 'sinatra/test/spec' context 'My app' should "show a default page" do get_it '/' should.be.ok body.should.equal 'My Default Page!' end ... end === Test Helpers See Sinatra::Test::Methods == Command line Run your sinatra file like: ruby myapp.rb [options] Options are: -h # help -p # set the port (default is 4567) -e # set the environment (default is development) -x # turn on the mutex lock (default is off) == Contribute cd where/you/keep/your/projects git clone git://github.com/bmizerany/sinatra.git cd your_project ln -s ../sinatra/ At the top of your sinatra.rb file: $:.unshift File.dirname(__FILE__) + '/sinatra/lib' require 'sinatra' get '/about' do "I'm running on Version " + Sinatra::VERSION end