Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Browse files

deleted book.html and changes.txt since they are now linked

  • Loading branch information...
commit 7d7770ba14f9f775eb9d2ba10230e10b290c0e54 1 parent 1089a9c
@kgrz kgrz authored
Showing with 0 additions and 1,684 deletions.
  1. +0 −508 _includes/CHANGES.txt
  2. +0 −1,176 _includes/book.html
View
508 _includes/CHANGES.txt
@@ -1,508 +0,0 @@
-= 1.0 / 2010-01-28 (prerelease)
-
- * It's now possible to register blocks to run after each request using
- after filters. After filters run at the end of each request, after
- routes and error handlers. (Jimmy Schementi)
-
- * Sinatra now uses Tilt <http://github.com/rtomayko/tilt> for rendering
- templates. This adds support for template caching, consistent
- template backtraces, and support for new template engines, like
- mustache and liquid. (Ryan Tomayko)
-
- * ERB, Erubis, and Haml templates are now compiled the first time
- they're rendered instead of being string eval'd on each invocation.
- Benchmarks show a 5x-10x improvement in render time. This also
- reduces the number of objects created, decreasing pressure on Ruby's
- GC. (Ryan Tomayko)
-
- * New 'settings' method gives access to options in both class and request
- scopes. This replaces the 'options' method. (Chris Wanstrath)
-
- * New boolean 'reload_templates' setting controls whether template files
- are reread from disk and recompiled on each request. Template read/compile
- is cached by default in all environments except development. (Ryan Tomayko)
-
- * New 'erubis' helper method for rendering ERB template with Erubis. The
- erubis gem is required. (Dylan Egan)
-
- * New 'cache_control' helper method provides a convenient way of
- setting the Cache-Control response header. Takes a variable number
- of boolean directives followed by a hash of value directives, like
- this: cache_control :public, :must_revalidate, :max_age => 60
- (Ryan Tomayko)
-
- * New 'expires' helper method is like cache_control but takes an
- integer number of seconds or Time object:
- expires 300, :public, :must_revalidate
- (Ryan Tomayko)
-
- * New request.secure? method for checking for an SSL connection.
- (Adam Wiggins)
-
- * Sinatra apps can now be run with a `-o <addr>` argument to specify
- the address to bind to. (Ryan Tomayko)
-
- * Rack::Session::Cookie is now added to the middleware pipeline when
- running in test environments if the :sessions option is set.
- (Simon Rozet)
-
- * Route handlers, before filters, templates, error mappings, and
- middleware are now resolved dynamically up the inheritance hierarchy
- when needed instead of duplicating the superclass's version when
- a new Sinatra::Base subclass is created. This should fix a variety
- of issues with extensions that need to add any of these things
- to the base class. (Ryan Tomayko)
-
- * Exception error handlers always override the raise_errors option now.
- Previously, all exceptions would be raised outside of the application
- when the raise_errors option was enabled, even if an error handler was
- defined for that exception. The raise_errors option now controls
- whether unhandled exceptions are raised (enabled) or if a generic 500
- error is returned (disabled). (Ryan Tomayko)
-
- * The X-Cascade response header is set to 'pass' when no matching route
- is found or all routes pass. (Josh Peek)
-
- * Filters do not run when serving static files anymore. (Ryan Tomayko)
-
-The following Sinatra features have been obsoleted (removed entirely) in
-the 1.0 release:
-
- * The `sinatra/test` library is obsolete. This includes the `Sinatra::Test`
- module, the `Sinatra::TestHarness` class, and the `get_it`, `post_it`,
- `put_it`, `delete_it`, and `head_it` helper methods. The
- [`Rack::Test` library](http://gitrdoc.com/brynary/rack-test) should
- be used instead.
-
- * Test framework specific libraries (`sinatra/test/spec`,
- `sinatra/test/bacon`,`sinatra/test/rspec`, etc.) are obsolete. See
- http://www.sinatrarb.com/testing.html for instructions on setting up a
- testing environment under each of these frameworks.
-
- * `Sinatra::Default` is obsolete; use `Sinatra::Base` instead.
- `Sinatra::Base` acts more like `Sinatra::Default` in development mode.
- For example, static file serving and sexy development error pages are
- enabled by default.
-
- * Auto-requiring template libraries in the `erb`, `builder`, `haml`,
- and `sass` methods is obsolete due to thread-safety issues. You must
- require the template libraries explicitly in your app.
-
- * The `:views_directory` option to rendering methods is obsolete; use
- `:views` instead.
-
- * The `:haml` and `:sass` options to rendering methods are obsolete.
- Template engine options should be passed in the second Hash argument
- instead.
-
- * The `use_in_file_templates` method is obsolete. Use
- `enable :inline_templates` or `set :inline_templates, 'path/to/file'`
-
- * The 'media_type' helper method is obsolete. Use 'mime_type' instead.
-
- * The 'mime' main and class method is obsolete. Use 'mime_type' instead.
-
- * The request-level `send_data` method is no longer supported.
-
- * The `Sinatra::Event` and `Sinatra::EventContext` classes are no longer
- supported. This may effect extensions written for versions prior to 0.9.2.
- See [Writing Sinatra Extensions](http://www.sinatrarb.com/extensions.html)
- for the officially supported extensions API.
-
- * The `set_option` and `set_options` methods are obsolete; use `set`
- instead.
-
- * The `:env` setting (`settings.env`) is obsolete; use `:environment`
- instead.
-
- * The request level `stop` method is obsolete; use `halt` instead.
-
- * The request level `entity_tag` method is obsolete; use `etag`
- instead.
-
- * The request level `headers` method (HTTP response headers) is obsolete;
- use `response['Header-Name']` instead.
-
- * `Sinatra.application` is obsolete; use `Sinatra::Application` instead.
-
- * Using `Sinatra.application = nil` to reset an application is obsolete.
- This should no longer be necessary.
-
- * Using `Sinatra.default_options` to set base configuration items is
- obsolete; use `Sinatra::Base.set(key, value)` instead.
-
- * The `Sinatra::ServerError` exception is obsolete. All exceptions raised
- within a request are now treated as internal server errors and result in
- a 500 response status.
-
- * The `:methodoverride' option to enable/disable the POST _method hack is
- obsolete; use `:method_override` instead.
-
-= 0.9.2 / 2009-05-18
-
- * This version is compatible with Rack 1.0. [Rein Henrichs]
-
- * The development-mode unhandled exception / error page has been
- greatly enhanced, functionally and aesthetically. The error
- page is used when the :show_exceptions option is enabled and an
- exception propagates outside of a route handler or before filter.
- [Simon Rozet / Matte Noble / Ryan Tomayko]
-
- * Backtraces that move through templates now include filenames and
- line numbers where possible. [#51 / S. Brent Faulkner]
-
- * All templates now have an app-level option for setting default
- template options (:haml, :sass, :erb, :builder). The app-level
- option value must be a Hash if set and is merged with the
- template options specified to the render method (Base#haml,
- Base#erb, Base#builder). [S. Brent Faulkner, Ryan Tomayko]
-
- * The method signature for all template rendering methods has
- been unified: "def engine(template, options={}, locals={})".
- The options Hash now takes the generic :views, :layout, and
- :locals options but also any template-specific options. The
- generic options are removed before calling the template specific
- render method. Locals may be specified using either the
- :locals key in the options hash or a second Hash option to the
- rendering method. [#191 / Ryan Tomayko]
-
- * The receiver is now passed to "configure" blocks. This
- allows for the following idiom in top-level apps:
- configure { |app| set :foo, app.root + '/foo' }
- [TJ Holowaychuck / Ryan Tomayko]
-
- * The "sinatra/test" lib is deprecated and will be removed in
- Sinatra 1.0. This includes the Sinatra::Test module and
- Sinatra::TestHarness class in addition to all the framework
- test helpers that were deprecated in 0.9.1. The Rack::Test
- lib should be used instead: http://gitrdoc.com/brynary/rack-test
- [#176 / Simon Rozet]
-
- * Development mode source file reloading has been removed. The
- "shotgun" (http://rtomayko.github.com/shotgun/) program can be
- used to achieve the same basic functionality in most situations.
- Passenger users should use the "tmp/always_restart.txt"
- file (http://tinyurl.com/c67o4h). [#166 / Ryan Tomayko]
-
- * Auto-requiring template libs in the erb, builder, haml, and
- sass methods is deprecated due to thread-safety issues. You must
- require the template libs explicitly in your app file. [Simon Rozet]
-
- * A new Sinatra::Base#route_missing method was added. route_missing
- is sent when no route matches the request or all route handlers
- pass. The default implementation forwards the request to the
- downstream app when running as middleware (i.e., "@app" is
- non-nil), or raises a NotFound exception when no downstream app
- is defined. Subclasses can override this method to perform custom
- route miss logic. [Jon Crosby]
-
- * A new Sinatra::Base#route_eval method was added. The method
- yields to the block and throws :halt with the result. Subclasses
- can override this method to tap into the route execution logic.
- [TJ Holowaychuck]
-
- * Fix the "-x" (enable request mutex / locking) command line
- argument. Passing -x now properly sets the :lock option.
- [S. Brent Faulkner, Ryan Tomayko]
-
- * Fix writer ("foo=") and predicate ("foo?") methods in extension
- modules not being added to the registering class.
- [#172 / Pat Nakajima]
-
- * Fix in-file templates when running alongside activesupport and
- fatal errors when requiring activesupport before sinatra
- [#178 / Brian Candler]
-
- * Fix various issues running on Google AppEngine.
- [Samuel Goebert, Simon Rozet]
-
- * Fix in-file templates __END__ detection when __END__ exists with
- other stuff on a line [Yoji Shidara]
-
-= 0.9.1.1 / 2009-03-09
-
- * Fix directory traversal vulnerability in default static files
- route. See [#177] for more info.
-
-= 0.9.1 / 2009-03-01
-
- * Sinatra now runs under Ruby 1.9.1 [#61]
-
- * Route patterns (splats, :named, or Regexp captures) are now
- passed as arguments to the block. [#140]
-
- * The "helpers" method now takes a variable number of modules
- along with the normal block syntax. [#133]
-
- * New request-level #forward method for middleware components: passes
- the env to the downstream app and merges the response status, headers,
- and body into the current context. [#126]
-
- * Requests are now automatically forwarded to the downstream app when
- running as middleware and no matching route is found or all routes
- pass.
-
- * New simple API for extensions/plugins to add DSL-level and
- request-level methods. Use Sinatra.register(mixin) to extend
- the DSL with all public methods defined in the mixin module;
- use Sinatra.helpers(mixin) to make all public methods defined
- in the mixin module available at the request level. [#138]
- See http://www.sinatrarb.com/extensions.html for details.
-
- * Named parameters in routes now capture the "." character. This makes
- routes like "/:path/:filename" match against requests like
- "/foo/bar.txt"; in this case, "params[:filename]" is "bar.txt".
- Previously, the route would not match at all.
-
- * Added request-level "redirect back" to redirect to the referring
- URL.
-
- * Added a new "clean_trace" option that causes backtraces dumped
- to rack.errors and displayed on the development error page to
- omit framework and core library backtrace lines. The option is
- enabled by default. [#77]
-
- * The ERB output buffer is now available to helpers via the @_out_buf
- instance variable.
-
- * It's now much easier to test sessions in unit tests by passing a
- ":session" option to any of the mock request methods. e.g.,
- get '/', {}, :session => { 'foo' => 'bar' }
-
- * The testing framework specific files ('sinatra/test/spec',
- 'sinatra/test/bacon', 'sinatra/test/rspec', etc.) have been deprecated.
- See http://sinatrarb.com/testing.html for instructions on setting up
- a testing environment with these frameworks.
-
- * The request-level #send_data method from Sinatra 0.3.3 has been added
- for compatibility but is deprecated.
-
- * Fix :provides causing crash on any request when request has no
- Accept header [#139]
-
- * Fix that ERB templates were evaluated twice per "erb" call.
-
- * Fix app-level middleware not being run when the Sinatra application is
- run as middleware.
-
- * Fixed some issues with running under Rack's CGI handler caused by
- writing informational stuff to stdout.
-
- * Fixed that reloading was sometimes enabled when starting from a
- rackup file [#110]
-
- * Fixed that "." in route patterns erroneously matched any character
- instead of a literal ".". [#124]
-
-= 0.9.0.4 / 2009-01-25
-
- * Using halt with more than 1 args causes ArgumentError [#131]
- * using halt in a before filter doesn't modify response [#127]
- * Add deprecated Sinatra::EventContext to unbreak plugins [#130]
- * Give access to GET/POST params in filters [#129]
- * Preserve non-nested params in nested params hash [#117]
- * Fix backtrace dump with Rack::Lint [#116]
-
-= 0.9.0.3 / 2009-01-21
-
- * Fall back on mongrel then webrick when thin not found. [#75]
- * Use :environment instead of :env in test helpers to
- fix deprecation warnings coming from framework.
- * Make sinatra/test/rspec work again [#113]
- * Fix app_file detection on windows [#118]
- * Fix static files with Rack::Lint in pipeline [#121]
-
-= 0.9.0.2 / 2009-01-18
-
- * Halting a before block should stop processing of routes [#85]
- * Fix redirect/halt in before filters [#85]
-
-= 0.9.0 / 2009-01-18
-
- * Works with and requires Rack >= 0.9.1
-
- * Multiple Sinatra applications can now co-exist peacefully within a
- single process. The new "Sinatra::Base" class can be subclassed to
- establish a blank-slate Rack application or middleware component.
- Documentation on using these features is forth-coming; the following
- provides the basic gist: http://gist.github.com/38605
-
- * Parameters with subscripts are now parsed into a nested/recursive
- Hash structure. e.g., "post[title]=Hello&post[body]=World" yields
- params: {'post' => {'title' => 'Hello', 'body' => 'World'}}.
-
- * Regular expressions may now be used in route pattens; captures are
- available at "params[:captures]".
-
- * New ":provides" route condition takes an array of mime types and
- matches only when an Accept request header is present with a
- corresponding type. [cypher]
-
- * New request-level "pass" method; immediately exits the current block
- and passes control to the next matching route.
-
- * The request-level "body" method now takes a block; evaluation is
- deferred until an attempt is made to read the body. The block must
- return a String or Array.
-
- * New "route conditions" system for attaching rules for when a route
- matches. The :agent and :host route options now use this system.
-
- * New "dump_errors" option controls whether the backtrace is dumped to
- rack.errors when an exception is raised from a route. The option is
- enabled by default for top-level apps.
-
- * Better default "app_file", "root", "public", and "views" location
- detection; changes to "root" and "app_file" automatically cascade to
- other options that depend on them.
-
- * Error mappings are now split into two distinct layers: exception
- mappings and custom error pages. Exception mappings are registered
- with "error(Exception)" and are run only when the app raises an
- exception. Custom error pages are registered with "error(status_code)",
- where "status_code" is an integer, and are run any time the response
- has the status code specified. It's also possible to register an error
- page for a range of status codes: "error(500..599)".
-
- * In-file templates are now automatically imported from the file that
- requires 'sinatra'. The use_in_file_templates! method is still available
- for loading templates from other files.
-
- * Sinatra's testing support is no longer dependent on Test::Unit. Requiring
- 'sinatra/test' adds the Sinatra::Test module and Sinatra::TestHarness
- class, which can be used with any test framework. The 'sinatra/test/unit',
- 'sinatra/test/spec', 'sinatra/test/rspec', or 'sinatra/test/bacon' files
- can be required to setup a framework-specific testing environment. See the
- README for more information.
-
- * Added support for Bacon (test framework). The 'sinatra/test/bacon' file
- can be required to setup Sinatra test helpers on Bacon::Context.
-
- * Deprecated "set_option" and "set_options"; use "set" instead.
-
- * Deprecated the "env" option ("options.env"); use "environment" instead.
-
- * Deprecated the request level "stop" method; use "halt" instead.
-
- * Deprecated the request level "entity_tag" method; use "etag" instead.
- Both "entity_tag" and "etag" were previously supported.
-
- * Deprecated the request level "headers" method (HTTP response headers);
- use "response['Header-Name']" instead.
-
- * Deprecated "Sinatra.application"; use "Sinatra::Application" instead.
-
- * Deprecated setting Sinatra.application = nil to reset an application.
- This should no longer be necessary.
-
- * Deprecated "Sinatra.default_options"; use
- "Sinatra::Default.set(key, value)" instead.
-
- * Deprecated the "ServerError" exception. All Exceptions are now
- treated as internal server errors and result in a 500 response
- status.
-
- * Deprecated the "get_it", "post_it", "put_it", "delete_it", and "head_it"
- test helper methods. Use "get", "post", "put", "delete", and "head",
- respectively, instead.
-
- * Removed Event and EventContext classes. Applications are defined in a
- subclass of Sinatra::Base; each request is processed within an
- instance.
-
-= 0.3.3 / 2009-01-06
-
- * Pin to Rack 0.4.0 (this is the last release on Rack 0.4)
-
- * Log unhandled exception backtraces to rack.errors.
-
- * Use RACK_ENV environment variable to establish Sinatra
- environment when given. Thin sets this when started with
- the -e argument.
-
- * BUG: raising Sinatra::NotFound resulted in a 500 response
- code instead of 404.
-
- * BUG: use_in_file_templates! fails with CR/LF (#45)
-
- * BUG: Sinatra detects the app file and root path when run under
- thin/passenger.
-
-= 0.3.2
-
- * BUG: Static and send_file read entire file into String before
- sending. Updated to stream with 8K chunks instead.
-
- * Rake tasks and assets for building basic documentation website.
- See http://sinatra.rubyforge.org
-
- * Various minor doc fixes.
-
-= 0.3.1
-
- * Unbreak optional path parameters [jeremyevans]
-
-= 0.3.0
-
- * Add sinatra.gemspec w/ support for github gem builds. Forks can now
- enable the build gem option in github to get free username-sinatra.gem
- builds: gem install username-sinatra.gem --source=http://gems.github.com/
-
- * Require rack-0.4 gem; removes frozen rack dir.
-
- * Basic RSpec support; require 'sinatra/test/rspec' instead of
- 'sinatra/test/spec' to use. [avdi]
-
- * before filters can modify request environment vars used for
- routing (e.g., PATH_INFO, REQUEST_METHOD, etc.) for URL rewriting
- type functionality.
-
- * In-file templates now uses @@ instead of ## as template separator.
-
- * Top-level environment test predicates: development?, test?, production?
-
- * Top-level "set", "enable", and "disable" methods for tweaking
- app options. [rtomayko]
-
- * Top-level "use" method for building Rack middleware pipelines
- leading to app. See README for usage. [rtomayko]
-
- * New "reload" option - set false to disable reloading in development.
-
- * New "host" option - host/ip to bind to [cschneid]
-
- * New "app_file" option - override the file to reload in development
- mode [cschneid]
-
- * Development error/not_found page cleanup [sr, adamwiggins]
-
- * Remove a bunch of core extensions (String#to_param, String#from_param,
- Hash#from_params, Hash#to_params, Hash#symbolize_keys, Hash#pass)
-
- * Various grammar and formatting fixes to README; additions on
- community and contributing [cypher]
-
- * Build RDoc using Hanna template: http://sinatrarb.rubyforge.org/api
-
- * Specs, documentation and fixes for splat'n routes [vic]
-
- * Fix whitespace errors across all source files. [rtomayko]
-
- * Fix streaming issues with Mongrel (body not closed). [bmizerany]
-
- * Fix various issues with environment not being set properly (configure
- blocks not running, error pages not registering, etc.) [cypher]
-
- * Fix to allow locals to be passed to ERB templates [cschneid]
-
- * Fix locking issues causing random errors during reload in development.
-
- * Fix for escaped paths not resolving static files [Matthew Walker]
-
-= 0.2.1
-
- * File upload fix and minor tweaks.
-
-= 0.2.0
-
- * Initial gem release of 0.2 codebase.
View
1,176 _includes/book.html
@@ -1,1176 +0,0 @@
-
-
-<div class='maruku_toc'><ul style='list-style: none;'><li><a href='#table_of_contents'>Table of Contents</a></li><li><a href='#introduction'>Introduction</a><ul style='list-style: none;'><li><a href='#what_is_sinatra'>What is Sinatra?</a></li><li><a href='#installation'>Installation</a><ul style='list-style: none;'><li><a href='#dependencies'>Dependencies</a></li><li><a href='#living_on_the_edge'>Living on the Edge</a></li></ul></li><li><a href='#hello_world_application'>Hello World Application</a></li><li><a href='#real_world_applications_in_sinatra'>Real World Applications in Sinatra</a><ul style='list-style: none;'><li><a href='#github_services'>Github Services</a></li><li><a href='#git_wiki'>Git Wiki</a></li><li><a href='#integrity'>Integrity</a></li><li><a href='#seinfeld_calendar'>Seinfeld Calendar</a></li></ul></li><li><a href='#about_this_book'>About this book</a></li></ul></li><li><a href='#routes'>Routes</a><ul style='list-style: none;'><li><a href='#http_methods'>HTTP methods</a></li><li><a href='#basic'>Basic</a></li><li><a href='#options'>Options</a></li><li><a href='#splats'>Splats</a></li><li><a href='#user_agent'>User agent</a></li><li><a href='#other_methods'>Other methods</a></li><li><a href='#the_put_and_delete_methods'>The PUT and DELETE methods</a></li><li><a href='#how_routes_are_looked_up'>How routes are looked up</a></li><li><a href='#splitting_into_multiple_files'>Splitting into multiple files</a></li></ul></li><li><a href='#handlers'>Handlers</a><ul style='list-style: none;'><li><a href='#structure'>Structure</a></li><li><a href='#form_parameters'>Form parameters</a><ul style='list-style: none;'><li><a href='#nested_form_parameters'>Nested form parameters</a></li></ul></li><li><a href='#redirect'>Redirect</a></li><li><a href='#sessions'>Sessions</a><ul style='list-style: none;'><li><a href='#default_cookie_based_sessions'>Default Cookie Based Sessions</a></li><li><a href='#memory_based_sessions'>Memory Based Sessions</a></li><li><a href='#memcached_based_sessions'>Memcached Based Sessions</a></li><li><a href='#file_based_sessions'>File Based Sessions</a></li><li><a href='#database_based_sessions'>Database Based Sessions</a></li></ul></li><li><a href='#cookies'>Cookies</a></li><li><a href='#status'>Status</a></li><li><a href='#authentication'>Authentication</a></li></ul></li><li><a href='#filters'>Filters</a><ul style='list-style: none;'><li><a href='#before_do'>before do&#8230;</a></li><li><a href='#nested_params_as_filter'>Handling of Rails like nested params (Sinatra &lt;= 3.0)</a></li></ul></li><li><a href='#views'>Views</a><ul style='list-style: none;'><li><a href='#template_languages'>Template Languages</a><ul style='list-style: none;'><li><a href='#haml'>Haml</a></li><li><a href='#sass'>Sass</a></li><li><a href='#erb'>Erb</a></li><li><a href='#builder'>Builder</a><ul style='list-style: none;'><li><a href='#atom_feed'>Atom Feed</a></li><li><a href='#rss_feed'>RSS Feed</a></li></ul></li></ul></li><li><a href='#layouts'>Layouts</a></li><li><a href='#avoiding_a_layout'>Avoiding a layout</a></li><li><a href='#in_file_views'>In File Views</a></li><li><a href='#partials'>Partials</a></li></ul></li><li><a href='#models'>Models</a><ul style='list-style: none;'><li><a href='#datamapper'>Datamapper</a></li><li><a href='#sequel'>Sequel</a></li><li><a href='#activerecord'>ActiveRecord</a></li></ul></li><li><a href='#helpers'>Helpers</a><ul style='list-style: none;'><li><a href='#the_basics'>The basics</a></li><li><a href='#implemention_of_rails_style_partials'>Implemention of rails style partials</a></li></ul></li><li><a href='#rack_middleware'>Rack Middleware</a></li><li><a href='#error_handling'>Error Handling</a><ul style='list-style: none;'><li><a href='#not_found'>not_found</a></li><li><a href='#error'>error</a></li><li><a href='#additional_information'>Additional Information</a></li></ul></li><li><a href='#configuration'>Configuration</a><ul style='list-style: none;'><li><a href='#use_sinatras_set_option'>Use Sinatra&#8217;s &#8220;set&#8221; option</a></li><li><a href='#external_config_file_via_the_configure_block'>External config file via the configure block</a></li><li><a href='#application_module__config_area'>Application module / config area</a></li></ul></li><li><a href='#deployment'>Deployment</a><ul style='list-style: none;'><li><a href='#heroku'>Heroku</a></li><li><a href='#deployment_lighttpd'>Lighttpd Proxied to Thin</a></li><li><a href='#deployment_passenger'>Passenger (mod rails)</a></li><li><a href='#deployment_fastcgi'>FastCGI</a><ul style='list-style: none;'><li><a href='#deployment_with_sinatra_version_09'>Deployment with Sinatra version 0.9</a></li><li><a href='#deployment_with_sinatra_version__03'>Deployment with Sinatra version &lt;= 0.3</a></li></ul></li></ul></li><li><a href='#contributing'>Contributing</a><ul style='list-style: none;'><li><a href='#how_can_i_clone_the_sinatra_repository'>How can I clone the Sinatra repository?</a></li><li><a href='#how_to_create_a_patch'>How to create a patch?</a></li><li><a href='#how_to_get_that_patch_into_the_official_sinatra'>How to get that patch into the official Sinatra?</a></li></ul></li></ul></div><hr />
-<h1 id='introduction'>Introduction</h1>
-
-<h2 id='what_is_sinatra'>What is Sinatra?</h2>
-
-<p>Sinatra is a Domain Specific Language (DSL) for quickly creating web-applications in Ruby.</p>
-
-<p>It keeps a minimal feature set, leaving the developer to use the tools that best suit them and their application.</p>
-
-<p>It doesn&#8217;t assume much about your application, apart from that:</p>
-
-<ul>
-<li>it will be written in Ruby programming language</li>
-
-<li>it will have URLs</li>
-</ul>
-
-<p>In Sinatra, you can write short <em>ad hoc</em> applications or mature, larger application with the same easiness. (See section &#8220;Real World Applications&#8221; later in this book.)</p>
-
-<p>You can use the power of various Rubygems and other libraries for Ruby available.</p>
-
-<p>Sinatra really shines when used for experiments and application mock-ups or for creating a quick interface for your code.</p>
-
-<p>It isn&#8217;t a <em>typical</em> Model-View-Controller framework, but ties specific URL directly to relevant Ruby code and returns its output in response. It does enable you, however, to write clean, properly organized applications: separating <em>views</em> from application code, for instance.</p>
-
-<h2 id='installation'>Installation</h2>
-
-<p>The simplest way to obtain Sinatra is through Rubygems</p>
-
-<pre><code>$ sudo gem install sinatra</code></pre>
-
-<h3 id='dependencies'>Dependencies</h3>
-
-<p>Sinatra depends on the <em>Rack</em> gem (<a href='http://rack.rubyforge.org'>http://rack.rubyforge.org</a>).</p>
-
-<p>For optimal experience, you should also install the <em>Haml</em> (<a href='http://haml.hamptoncatlin.com'>http://haml.hamptoncatlin.com</a>) and <em>Builder</em> gem (<a href='http://builder.rubyforge.org'>http://builder.rubyforge.org</a>), which simplifies working with views.</p>
-
-<pre><code>$ sudo gem install builder haml</code></pre>
-
-<h3 id='living_on_the_edge'>Living on the Edge</h3>
-
-<p>The <em>edge</em> version of Sinatra lives in its Git repository, available at <strong><a href='http://github.com/sinatra/sinatra/tree/master'>http://github.com/sinatra/sinatra/tree/master</a></strong>.</p>
-
-<p>You can use the <em>edge</em> version to try new functionality or to contribute to the framework. You need to have Git version control software installed (<a href='http://www.git-scm.com'>http://www.git-scm.com</a>). Then follow these steps:</p>
-
-<ol>
-<li>cd where/you/keep/your/projects</li>
-
-<li>git clone git://github.com/sinatra/sinatra.git</li>
-
-<li>cd sinatra</li>
-
-<li>cd your_project</li>
-
-<li>ln -s ../sinatra</li>
-</ol>
-
-<p>Then add this to your application:</p>
-
-<pre><code>$:.unshift File.dirname(__FILE__) + &#39;/sinatra/lib&#39;
-require &#39;sinatra&#39;</code></pre>
-
-<p>You can check the version you are running by adding this route</p>
-
-<pre><code>get &#39;/about&#39; do
- &quot;I&#39;m running on Version &quot; + Sinatra::VERSION
-end</code></pre>
-
-<p>and loading <code>http://localhost:4567/about</code> in your browser.</p>
-
-<h2 id='hello_world_application'>Hello World Application</h2>
-
-<p>Sinatra is installed and you&#8217;re done eating cake, how about making your first application?</p>
-
-<pre><code># hello_world.rb
-require &#39;rubygems&#39;
-require &#39;sinatra&#39;
-
-get &#39;/&#39; do
- &quot;Hello world, it&#39;s #{Time.now} at the server!&quot;
-end</code></pre>
-
-<p>Run this application by <code>$ ruby hello_world.rb</code> and load <code>http://localhost:4567</code> in your browser.</p>
-
-<p>As you can see, Sinatra doesn&#8217;t force you to setup much infrastructure: a request to some URL (<em>root</em> URL in this case) evaluates some Ruby code and returns some text in response.</p>
-
-<h2 id='real_world_applications_in_sinatra'>Real World Applications in Sinatra</h2>
-
-<h3 id='github_services'>Github Services</h3>
-
-<p>Git hosting provider Github uses Sinatra for post-receive hooks, calling user specified services/URLs, whenever someone pushes to their repository:</p>
-
-<ul>
-<li><a href='http://github.com/blog/53-github-services-ipo'>http://github.com/blog/53-github-services-ipo</a></li>
-
-<li><a href='http://github.com/guides/post-receive-hooks'>http://github.com/guides/post-receive-hooks</a></li>
-
-<li><a href='http://github.com/pjhyett/github-services'>http://github.com/pjhyett/github-services</a></li>
-</ul>
-
-<h3 id='git_wiki'>Git Wiki</h3>
-
-<p>Git Wiki is minimal Wiki engine powered by Sinatra and Git. See also various forks with additional functionality.</p>
-
-<ul>
-<li><a href='http://github.com/sr/git-wiki'>http://github.com/sr/git-wiki</a></li>
-
-<li><a href='http://github.com/sr/git-wiki/network'>http://github.com/sr/git-wiki/network</a></li>
-</ul>
-
-<h3 id='integrity'>Integrity</h3>
-
-<p>Integrity is small and clean <em>continuous integration</em> service using Sinatra, watching for failing builds of your codebase and notifying you by various channels.</p>
-
-<ul>
-<li><a href='http://www.integrityapp.com/'>http://www.integrityapp.com/</a></li>
-
-<li><a href='http://github.com/foca/integrity'>http://github.com/foca/integrity</a></li>
-</ul>
-
-<h3 id='seinfeld_calendar'>Seinfeld Calendar</h3>
-
-<p>Seinfeld Calendar is a fun application tracking your contributions to open-source projects, displaying your &#8220;streaks&#8221;, ie. continuous commits to Github repositories.</p>
-
-<ul>
-<li><a href='http://www.calendaraboutnothing.com'>http://www.calendaraboutnothing.com</a></li>
-
-<li><a href='http://github.com/entp/seinfeld'>http://github.com/entp/seinfeld</a></li>
-</ul>
-
-<h2 id='about_this_book'>About this book</h2>
-
-<p>This book will assume you have a basic knowledge of the Ruby scripting language and a working Ruby interpreter.</p>
-
-<p>For more information about the Ruby language visit the following links:</p>
-
-<ul>
-<li><a href='http://www.ruby-lang.org'>http://www.ruby-lang.org</a></li>
-
-<li><a href='http://www.ruby-lang.org/en/documentation/ruby-from-other-languages/'>http://www.ruby-lang.org/en/documentation/ruby-from-other-languages/</a></li>
-
-<li><a href='http://www.ruby-doc.org'>http://www.ruby-doc.org</a></li>
-
-<li><a href='http://www.ruby-doc.org/core-1.8.7/index.html'>http://www.ruby-doc.org/core-1.8.7/index.html</a></li>
-
-<li><a href='http://www.ruby-doc.org/docs/ProgrammingRuby/'>http://www.ruby-doc.org/docs/ProgrammingRuby/</a></li>
-</ul>
-<hr />
-<h1 id='routes'>Routes</h1>
-
-<h2 id='http_methods'>HTTP methods</h2>
-
-<p>Sinatra&#8217;s routes are designed to respond to the HTTP request methods.</p>
-
-<ul>
-<li>GET</li>
-
-<li>POST</li>
-
-<li>PUT</li>
-
-<li>DELETE</li>
-</ul>
-
-<h2 id='basic'>Basic</h2>
-
-<p>Simple</p>
-
-<pre><code>get &#39;/hi&#39; do
- ...
-end</code></pre>
-
-<p>With params</p>
-
-<pre><code>get &#39;/:name&#39; do
- # matches /sinatra and the like and sets params[:name]
-end</code></pre>
-
-<h2 id='options'>Options</h2>
-
-<h2 id='splats'>Splats</h2>
-
-<pre><code>get &#39;/say/*/to/*&#39; do
- # matches /say/hello/to/world
- params[&quot;splat&quot;] # =&gt; [&quot;hello&quot;, &quot;world&quot;]
-end
-
-get &#39;/download/*.*&#39; do
- # matches /download/path/to/file.xml
- params[&quot;splat&quot;] # =&gt; [&quot;path/to/file&quot;, &quot;xml&quot;]
-end</code></pre>
-
-<h2 id='user_agent'>User agent</h2>
-
-<pre><code>get &#39;/foo&#39;, :agent =&gt; /Songbird (\d\.\d)[\d\/]*?/ do
- &quot;You&#39;re using Songbird version #{params[:agent][0]}&quot;
-end
-
-get &#39;/foo&#39; do
- # matches non-songbird browsers
-end</code></pre>
-
-<h2 id='other_methods'>Other methods</h2>
-
-<p>Other methods are requested exactly the same as &#8220;get&#8221; routes. You simply use the <code>post</code>, <code>put</code>, or <code>delete</code> functions to define the route, rather then the <code>get</code> one. To access POSTed parameters, use <code>params[:xxx]</code> where xxx is the name of the form element that was posted.</p>
-
-<pre><code>post &#39;/foo&#39; do
- &quot;You just asked for foo, with post param bar equal to #{params[:bar]}&quot;
-end</code></pre>
-
-<h2 id='the_put_and_delete_methods'>The PUT and DELETE methods</h2>
-
-<p>Since browsers don&#8217;t natively support the PUT and DELETE methods, a hacky workaround has been adopted by the web community. Simply add a hidden element with the name &#8220;_method&#8221; and the value equal to the HTTP method you want to use. The form itself is sent as a POST, but Sinatra will interpret it as the desired method. For example:</p>
-
-<pre><code>&lt;form method=&quot;post&quot; action=&quot;/destroy_it&quot;&gt;
- &lt;input name=&quot;_method&quot; value=&quot;delete&quot; /&gt;
- &lt;div&gt;&lt;button type=&quot;submit&quot;&gt;Destroy it&lt;/button&gt;&lt;/div&gt;
-&lt;/form&gt;</code></pre>
-
-<p>When you want to use PUT or DELETE from a client that does support them (like Curl, or ActiveResource), just go ahead and use them as you normally would, and ignore the <code>_method</code> advice above. That is only for hacking in support for browsers.</p>
-
-<h2 id='how_routes_are_looked_up'>How routes are looked up</h2>
-
-<p>Each time you add a new route to your application, it gets compiled down into a regular expression that will match it. That is stored in an array along with the handler block attached to that route.</p>
-
-<p>When a new request comes in, each regex is run in turn, until one matches. Then the the handler (the code block) attached to that route gets executed.</p>
-
-<h2 id='splitting_into_multiple_files'>Splitting into multiple files</h2>
-
-<p>Because Sinatra clears out your routes and reloads your application on every request in development mode, you can&#8217;t use require to load files containing your routes because these will only be loaded when the application starts (and reloaded even on the first request!) Instead, use <a href='http://www.ruby-doc.org/core/classes/Kernel.html#M005966' title='Ruby RDoc: load'>load</a>:</p>
-
-<pre><code># application.rb
-require &#39;rubygems&#39;
-require &#39;sinatra&#39;
-
-get &#39;/&#39; do
- &quot;Hello world!&quot;
-end
-
-load &#39;more_routes.rb&#39;</code></pre>
-
-<p>and</p>
-
-<pre><code># more_routes.rb
-
-get &#39;/foo&#39; do
- &quot;Bar? How unimaginative.&quot;
-end</code></pre>
-<hr />
-<h1 id='handlers'>Handlers</h1>
-
-<h2 id='structure'>Structure</h2>
-
-<p>Handler is the generic term that Sinatra uses for the &#8220;controllers&#8221;. A handler is the initial point of entry for new HTTP requests into your application.</p>
-
-<p>To find more about the routes, head to the <a href='#routes'>Routes section</a></p>
-
-<h2 id='form_parameters'>Form parameters</h2>
-
-<p>In handlers you can reach submitted form parameters directly via the params hash:</p>
-
-<pre><code>get &#39;/&#39; do
- params[&#39;post&#39;]
-end</code></pre>
-
-<h3 id='nested_form_parameters'>Nested form parameters</h3>
-
-<p>The support of Rails like nested parameters is built-in since Sinatra version 9.0. Before this version you have to <a href='#nested_params_as_filter'>implement this functionality as a before filter</a>!</p>
-
-<pre><code>&lt;form&gt;
- &lt;input ... name=&quot;post[title]&quot; /&gt;
- &lt;input ... name=&quot;post[body]&quot; /&gt;
- &lt;input ... name=&quot;post[author]&quot; /&gt;
-&lt;/form&gt;</code></pre>
-
-<p>The parameters in this case became as a hash:</p>
-
-<pre><code>{&quot;post&quot;=&gt;{ &quot;title&quot;=&gt;&quot;&quot;, &quot;body&quot;=&gt;&quot;&quot;, &quot;author&quot;=&gt;&quot;&quot; }}</code></pre>
-
-<p>Therefore in handlers you can use nested parameters like a regular hash:</p>
-
-<pre><code>params[&#39;post&#39;][&#39;title&#39;]</code></pre>
-
-<h2 id='redirect'>Redirect</h2>
-
-<p>The redirect helper is a shortcut to a common http response code (302).</p>
-
-<p>Basic usage is easy:</p>
-
-<pre><code>redirect &#39;/&#39;
-
-redirect &#39;/posts/1&#39;
-
-redirect &#39;http://www.google.com&#39;</code></pre>
-
-<p>The redirect actually sends back a Location header to the browser, and the browser makes a followup request to the location indicated. Since the browser makes that followup request, you can redirect to any page, in your application, or another site entirely.</p>
-
-<p>The flow of requests during a redirect is: Browser → Server (redirect to &#8217;/&#8217;) → Browser (request &#8217;/&#8217;) → Server (result for &#8217;/&#8217;)</p>
-
-<p>To force Sinatra to send a different response code, it&#8217;s very simple:</p>
-
-<pre><code>redirect &#39;/&#39;, 303 # forces the 303 return code
-
-redirect &#39;/&#39;, 307 # forces the 307 return code</code></pre>
-
-<h2 id='sessions'>Sessions</h2>
-
-<h3 id='default_cookie_based_sessions'>Default Cookie Based Sessions</h3>
-
-<p>Sinatra ships with basic support for cookie based sessions. To enable it, in a configure block, or at the top of your application, you just need to enable the option.</p>
-
-<pre><code>enable :sessions
-
-get &#39;/&#39; do
- session[&quot;counter&quot;] ||= 0
- session[&quot;counter&quot;] += 1
-
- &quot;You&#39;ve hit this page #{session[&quot;counter&quot;]} time(s)&quot;
-end</code></pre>
-
-<p>The downside to this session approach is that all the data is stored in the cookie. Since cookies have a fairly hard limit of 4 kilobytes, you can&#8217;t store much data. The other issue is that cookies are not tamper proof. The user can change any data in their session. But&#8230; it is easy, and it doesn&#8217;t have the scaling problems that memory or database backed sessions run into.</p>
-
-<h3 id='memory_based_sessions'>Memory Based Sessions</h3>
-
-<h3 id='memcached_based_sessions'>Memcached Based Sessions</h3>
-
-<h3 id='file_based_sessions'>File Based Sessions</h3>
-
-<h3 id='database_based_sessions'>Database Based Sessions</h3>
-
-<h2 id='cookies'>Cookies</h2>
-
-<p>Cookies are a fairly simple thing to use in Sinatra, but they have a few quirks.</p>
-
-<p>Lets first look at the simple use case:</p>
-
-<pre><code>require &#39;rubygems&#39;
-require &#39;sinatra&#39;
-
-get &#39;/&#39; do
- # Get the string representation
- cookie = request.cookies[&quot;thing&quot;]
-
- # Set a default
- cookie ||= 0
-
- # Convert to an integer
- cookie = cookie.to_i
-
- # Do something with the value
- cookie += 1
-
- # Reset the cookie
- set_cookie(&quot;thing&quot;, cookie)
-
- # Render something
- &quot;Thing is now: #{cookie}&quot;
-end</code></pre>
-
-<p>Setting a path, expiration date, or domain gets a little more complicated - see the source code for set_cookie if you want to dig deeper.</p>
-
-<pre><code>set_cookie(&quot;thing&quot;, :domain =&gt; myDomain,
- :path =&gt; myPath,
- :expires =&gt; Date.new)</code></pre>
-
-<p>That&#8217;s the easy stuff with cookies - It can also serialize Array objects, separating them with ampersands (&amp;), but when they come back, it doesn&#8217;t deserialize or split them in any way, it hands you the raw, encoded string for your parsing pleasure.</p>
-
-<h2 id='status'>Status</h2>
-
-<p>If you want to set your own status response instead of the normal 200 (Success), you can use the <code>status</code>-helper to set the code, and then still render normally:</p>
-
-<pre><code>get &#39;/&#39; do
- status 404
- &quot;Not found&quot;
-end</code></pre>
-
-<p>Alternatively you can use <code>throw :halt, [404, &quot;Not found&quot;]</code> to immediately stop any further actions and return the specified status code and string to the client. <code>throw</code> supports more options in this regard, see the appropriate section for more info.</p>
-
-<h2 id='authentication'>Authentication</h2>
-<hr />
-<h1 id='filters'>Filters</h1>
-
-<h2 id='before_do'>before do&#8230;</h2>
-
-<p>These are run in Sinatra::EventContext</p>
-
-<pre><code>before do
- # .. this code will run before each event ..
-end</code></pre>
-
-<h2 id='nested_params_as_filter'>Handling of Rails like nested params (Sinatra &lt;= 3.0)</h2>
-
-<p>If you want to use a form with parameters like this (aka. Rails&#8217; nested params):</p>
-
-<pre><code>&lt;form&gt;
- &lt;input ... name=&quot;post[title]&quot; /&gt;
- &lt;input ... name=&quot;post[body]&quot; /&gt;
- &lt;input ... name=&quot;post[author]&quot; /&gt;
-&lt;/form&gt;</code></pre>
-
-<p>You have convert parameters to a hash. You can easily do this with a before filter:</p>
-
-<pre><code>before do
- new_params = {}
- params.each_pair do |full_key, value|
- this_param = new_params
- split_keys = full_key.split(/\]\[|\]|\[/)
- split_keys.each_index do |index|
- break if split_keys.length == index + 1
- this_param[split_keys[index]] ||= {}
- this_param = this_param[split_keys[index]]
- end
- this_param[split_keys.last] = value
- end
- request.params.replace new_params
-end</code></pre>
-
-<p>Then parameters became:</p>
-
-<pre><code>{&quot;post&quot;=&gt;{ &quot;title&quot;=&gt;&quot;&quot;, &quot;body&quot;=&gt;&quot;&quot;, &quot;author&quot;=&gt;&quot;&quot; }}</code></pre>
-<hr />
-<h1 id='views'>Views</h1>
-
-<p>All file-based views are looked up in:</p>
-
-<pre><code>root
- | - views/</code></pre>
-
-<h2 id='template_languages'>Template Languages</h2>
-
-<h3 id='haml'>Haml</h3>
-
-<pre><code>get &#39;/&#39; do
- haml :index
-end</code></pre>
-
-<p>This will render ./views/index.haml</p>
-
-<h3 id='sass'>Sass</h3>
-
-<pre><code>get &#39;/&#39; do
- sass :styles
-end</code></pre>
-
-<p>This will render ./views/styles.sass</p>
-
-<h3 id='erb'>Erb</h3>
-
-<pre><code>get &#39;/&#39; do
- erb :index
-end</code></pre>
-
-<p>This will render ./views/index.erb</p>
-
-<h3 id='builder'>Builder</h3>
-
-<pre><code>get &#39;/&#39; do
- builder :index
-end</code></pre>
-
-<p>This will render ./views/index.builder</p>
-
-<pre><code>get &#39;/&#39; do
- builder do |xml|
- xml.node do
- xml.subnode &quot;Inner text&quot;
- end
- end
-end</code></pre>
-
-<p>This will render the xml inline, directly from the handler.</p>
-
-<h4 id='atom_feed'>Atom Feed</h4>
-
-<h4 id='rss_feed'>RSS Feed</h4>
-
-<p>Assume that your site url is http://liftoff.msfc.nasa.gov/.</p>
-
-<pre><code>get &#39;/rss.xml&#39; do
- builder do |xml|
- xml.instruct! :xml, :version =&gt; &#39;1.0&#39;
- xml.rss :version =&gt; &quot;2.0&quot; do
- xml.channel do
- xml.title &quot;Liftoff News&quot;
- xml.description &quot;Liftoff to Space Exploration.&quot;
- xml.link &quot;http://liftoff.msfc.nasa.gov/&quot;
-
- @posts.each do |post|
- xml.item do
- xml.title post.title
- xml.link &quot;http://liftoff.msfc.nasa.gov/posts/#{post.id}&quot;
- xml.description post.body
- xml.pubDate Time.parse(post.created_at.to_s).rfc822()
- xml.guid &quot;http://liftoff.msfc.nasa.gov/posts/#{post.id}&quot;
- end
- end
- end
- end
- end
-end</code></pre>
-
-<p>This will render the rss inline, directly from the handler.</p>
-
-<h2 id='layouts'>Layouts</h2>
-
-<p>Layouts are simple in Sinatra. Put a file in your views directory named &#8220;layout.erb&#8221;, &#8220;layout.haml&#8221;, or &#8220;layout.builder&#8221;. When you render a page, the appropriate layout will be grabbed (of the same filetype), and used.</p>
-
-<p>The layout itself should call <code>yield</code> at the point you want the content to be included.</p>
-
-<p>An example haml layout file could look something like this:</p>
-
-<pre><code>%html
- %head
- %title SINATRA BOOK
- %body
- #container
- = yield</code></pre>
-
-<h2 id='avoiding_a_layout'>Avoiding a layout</h2>
-
-<dl>
-<dt>Sometimes you don&#8217;t want the layout rendered. In your render method just pass</dt>
-
-<dd>
-<p>layout =&gt; false, and you&#8217;re good.</p>
-
-<p>get &#8217;/&#8217; do haml :index, :layout =&gt; false end</p>
-</dd>
-</dl>
-
-<h2 id='in_file_views'>In File Views</h2>
-
-<p>This one is cool:</p>
-
-<pre><code>get &#39;/&#39; do
- haml :index
-end
-
-use_in_file_templates!
-
-__END__
-
-@@ layout
-X
-= yield
-X
-
-@@ index
-%div.title Hello world!!!!!</code></pre>
-
-<p>Try it!</p>
-
-<h2 id='partials'>Partials</h2>
-<hr />
-<h1 id='models'>Models</h1>
-
-<h2 id='datamapper'>Datamapper</h2>
-
-<p>Start out by getting the DataMapper gem if you don&#8217;t already have it, and then making sure it&#8217;s in your applicaton. A call to <code>setup</code> as usual will get the show started, and this example will include a &#8216;Post&#8217; model.</p>
-
-<pre><code>require &#39;rubygems&#39;
-require &#39;sinatra&#39;
-require &#39;datamapper&#39;
-
-DataMapper::setup(:default, &quot;sqlite://#{Dir.pwd}/blog.db&quot;)
-
-class Post
- include DataMapper::Resource
- property :id, Serial
- property :title, String
- property :body, Text
- property :created_at, DateTime
-end
-
-# automatically create the post table
-Post.auto_migrate! unless Post.table_exists?</code></pre>
-
-<p>Once that is all well and good, you can actually start developing your application!</p>
-
-<pre><code>get &#39;/&#39; do
- # get the latest 20 posts
- @posts = Post.get(:order =&gt; [ :id.desc ], :limit =&gt; 20)
- erb :index
-end</code></pre>
-
-<p>Finally, the view at <code>./view/index.html</code>:</p>
-
-<pre><code>&lt;% for post in @posts %&gt;
- &lt;h3&gt;&lt;%= post.title %&gt;&lt;/h3&gt;
- &lt;p&gt;&lt;%= post.body %&gt;&lt;/p&gt;
-&lt;% end %&gt;</code></pre>
-
-<h2 id='sequel'>Sequel</h2>
-
-<p>Require the Sequel gem in your app:</p>
-
-<pre><code>require &#39;rubygems&#39;
-require &#39;sinatra&#39;
-require &#39;sequel&#39;</code></pre>
-
-<p>Use a simple in-memory DB:</p>
-
-<pre><code>DB = Sequel.sqlite</code></pre>
-
-<p>Create a table:</p>
-
-<pre><code>DB.create_table :links do
- primary_key :id
- varchar :title
- varchar :link
-end</code></pre>
-
-<p>Create the Model class:</p>
-
-<pre><code>class Link &lt; Sequel::Model
-end</code></pre>
-
-<p>Create the route:</p>
-
-<pre><code>get &#39;/&#39; do
- @links = Link.all
- haml :links
-end</code></pre>
-
-<h2 id='activerecord'>ActiveRecord</h2>
-
-<p>First require ActiveRecord gem in your application, then give your database connection settings:</p>
-
-<pre><code>require &#39;rubygems&#39;
-require &#39;sinatra&#39;
-require &#39;activerecord&#39;
-
-ActiveRecord::Base.establish_connection(
- :adapter =&gt; &#39;sqlite3&#39;,
- :dbfile =&gt; &#39;sinatra_application.sqlite3.db&#39;
-)</code></pre>
-
-<p>Now you can create and use ActiveRecord models just like in Rails (the example assumes you already have a &#8216;posts&#8217; table in your database):</p>
-
-<pre><code>class Post &lt; ActiveRecord::Base
-end
-
-get &#39;/&#39; do
- @posts = Post.all()
- erb :index
-end</code></pre>
-
-<p>This will render ./views/index.erb:</p>
-
-<pre><code>&lt;% for post in @posts %&gt;
- &lt;h1&gt;&lt;%= post.title %&gt;&lt;/h1&gt;
-&lt;% end %&gt;</code></pre>
-<hr />
-<h1 id='helpers'>Helpers</h1>
-
-<h2 id='the_basics'>The basics</h2>
-
-<p>It is ill-advised to create helpers on the root level of your application. They muddy the global namespace, and don&#8217;t have easy access to the request, response, session or cookie variables.</p>
-
-<p>Instead, use the handy helpers method to install methods on <code>Sinatra::EventContext</code> for use inside events and templates.</p>
-
-<p>Example:</p>
-
-<pre><code>helpers do
- def bar(name)
- &quot;#{name}bar&quot;
- end
-end
-
-get &#39;/:name&#39; do
- bar(params[:name])
-end</code></pre>
-
-<h2 id='implemention_of_rails_style_partials'>Implemention of rails style partials</h2>
-
-<p>Using partials in your views is a great way to keep them clean. Since Sinatra takes the hands off approach to framework design, you&#8217;ll have to implement a partial handler yourself.</p>
-
-<p>Here is a really basic version:</p>
-
-<pre><code># Usage: partial :foo
-helpers do
- def partial(page, options={})
- haml page, options.merge!(:layout =&gt; false)
- end
-end</code></pre>
-
-<p>A more advanced version that would handle passing local options, and looping over a hash would look like:</p>
-
-<pre><code># Render the page once:
-# Usage: partial :foo
-#
-# foo will be rendered once for each element in the array, passing in a local variable named &quot;foo&quot;
-# Usage: partial :foo, :collection =&gt; @my_foos
-
-helpers do
- def partial(template, *args)
- options = args.extract_options!
- options.merge!(:layout =&gt; false)
- if collection = options.delete(:collection) then
- collection.inject([]) do |buffer, member|
- buffer &lt;&lt; haml(template, options.merge(
- :layout =&gt; false,
- :locals =&gt; {template.to_sym =&gt; member}
- )
- )
- end.join(&quot;\n&quot;)
- else
- haml(template, options)
- end
- end
-end</code></pre>
-<hr />
-<h1 id='rack_middleware'>Rack Middleware</h1>
-
-<p>Sinatra rides on <a href='http://rack.rubyforge.org/'>Rack</a>, a minimal standard interface for Ruby web frameworks. One of Rack’s most interesting capabilities for application developers is support for &#8220;middleware&#8221; &#8211; components that sit between the server and your application monitoring and/or manipulating the HTTP request/response to provide various types of common functionality.</p>
-
-<p>Sinatra makes building Rack middleware pipelines a cinch via a top-level <code>use</code> method:</p>
-
-<pre><code>require &#39;sinatra&#39;
-require &#39;my_custom_middleware&#39;
-
-use Rack::Lint
-use MyCustomMiddleware
-
-get &#39;/hello&#39; do
- &#39;Hello World&#39;
-end</code></pre>
-
-<p>The semantics of &#8220;use&#8221; are identical to those defined for the <a href='http://rack.rubyforge.org/doc/classes/Rack/Builder.html'>Rack::Builder</a> DSL (most frequently used from rackup files). For example, the use method accepts multiple/variable args as well as blocks:</p>
-
-<pre><code>use Rack::Auth::Basic do |username, password|
- username == &#39;admin&#39; &amp;&amp; password == &#39;secret&#39;
-end</code></pre>
-
-<p>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.</p>
-<hr />
-<h1 id='error_handling'>Error Handling</h1>
-
-<h2 id='not_found'>not_found</h2>
-
-<p>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.)</p>
-
-<p>Whenever NotFound is raised this will be called</p>
-
-<pre><code>not_found do
- &#39;This is nowhere to be found&#39;
-end</code></pre>
-
-<h2 id='error'>error</h2>
-
-<p>By default error will catch Sinatra::ServerError</p>
-
-<p>Sinatra will pass you the error via the ‘sinatra.error’ in request.env</p>
-
-<pre><code>error do
- &#39;Sorry there was a nasty error - &#39; + request.env[&#39;sinatra.error&#39;].name
-end</code></pre>
-
-<p>Custom error mapping:</p>
-
-<pre><code>error MyCustomError do
- &#39;So what happened was...&#39; + request.env[&#39;sinatra.error&#39;].message
-end</code></pre>
-
-<p>then if this happens:</p>
-
-<pre><code>get &#39;/&#39; do
- raise MyCustomError, &#39;something bad&#39;
-end</code></pre>
-
-<p>you gets this:</p>
-
-<pre><code>So what happened was... something bad</code></pre>
-
-<h2 id='additional_information'>Additional Information</h2>
-
-<p>Because Sinatra give you a default not_found and error 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:</p>
-
-<pre><code>configure :production do
- not_found do
- &quot;We&#39;re so sorry, but we don&#39;t what this is&quot;
- end
-
- error do
- &quot;Something really nasty happened. We&#39;re on it!&quot;
- end
-end</code></pre>
-<hr />
-<h1 id='configuration'>Configuration</h1>
-
-<h2 id='use_sinatras_set_option'>Use Sinatra&#8217;s &#8220;set&#8221; option</h2>
-
-<p>Configure blocks are not executed in the event context, and don&#8217;t have access to the same instance variables. To store a piece of information that you want to access in your routes, use <code>set</code>.</p>
-
-<pre><code>configure :development do
- set :dbname, &#39;devdb&#39;
-end
-
-configure :production do
- set :dbname, &#39;productiondb&#39;
-end</code></pre>
-
-<p>&#8230;</p>
-
-<pre><code>get &#39;/whatdb&#39; do
- &#39;We are using the database named &#39; + options.dbname
-end</code></pre>
-
-<h2 id='external_config_file_via_the_configure_block'>External config file via the configure block</h2>
-
-<h2 id='application_module__config_area'>Application module / config area</h2>
-<hr />
-<h1 id='deployment'>Deployment</h1>
-
-<h2 id='heroku'>Heroku</h2>
-
-<p>This is the easiest configuration + deployment option. <a href='http://www.heroku.com'>Heroku</a> has full support for Sinatra applications. Deploying to Heroku is simply a matter of pushing to a remote git repository.</p>
-
-<p>Steps to deploy to Heroku:</p>
-
-<ul>
-<li>Create an <a href='http://heroku.com/signup'>account</a> if you don&#8217;t have one</li>
-
-<li><code>sudo gem install heroku</code></li>
-
-<li>Make a config.ru in the root-directory</li>
-
-<li>Create the app on heroku</li>
-
-<li>Push to it</li>
-</ul>
-
-<ol>
-<li>
-<p>An example config.ru file (Heroku sets <code>RACK_ENV</code> to production for you)</p>
-
-<pre><code>require &quot;myapp&quot;
-
-run Sinatra::Application</code></pre>
-</li>
-
-<li>
-<p>Create the app and push to it</p>
-
-<pre><code>From the root-directory of the application
-
-$ heroku create &lt;app-name&gt; # This will add heroku as a remote
-$ git push heroku master</code></pre>
-</li>
-</ol>
-
-<p>For more details see <a href='http://github.com/sinatra/heroku-sinatra-app'>this</a></p>
-
-<h2 id='deployment_lighttpd'>Lighttpd Proxied to Thin</h2>
-
-<p>This will cover how to deploy Sinatra to a load balanced reverse proxy setup using Lighttpd and Thin.</p>
-
-<ol>
-<li>
-<p>Install Lighttpd and Thin</p>
-
-<pre><code># Figure out lighttpd yourself, it should be handled by your
-# linux distro&#39;s package manager
-
-# For thin:
-gem install thin</code></pre>
-</li>
-
-<li>
-<p>Create your rackup file &#8211; the <code>require &#39;app&#39;</code> line should require the actual Sinatra app you have written.</p>
-
-<pre><code>## This is not needed for Thin &gt; 1.0.0
-ENV[&#39;RACK_ENV&#39;] = &quot;production&quot;
-
-require &#39;app&#39;
-
-run Sinatra::Application</code></pre>
-</li>
-
-<li>
-<p>Setup a config.yml - change the /path/to/my/app path to reflect reality.</p>
-
-<pre><code>---
- environment: production
- chdir: /path/to/my/app
- address: 127.0.0.1
- user: root
- group: root
- port: 4567
- pid: /path/to/my/app/thin.pid
- rackup: /path/to/my/app/config.ru
- log: /path/to/my/app/thin.log
- max_conns: 1024
- timeout: 30
- max_persistent_conns: 512
- daemonize: true</code></pre>
-</li>
-
-<li>
-<p>Setup lighttpd.conf - change mydomain to reflect reality. Also make sure the first port here matches up with the port setting in config.yml.</p>
-
-<pre><code>$HTTP[&quot;host&quot;] =~ &quot;(www\.)?mydomain\.com&quot; {
- proxy.balance = &quot;fair&quot;
- proxy.server = (&quot;/&quot; =&gt;
- (
- ( &quot;host&quot; =&gt; &quot;127.0.0.1&quot;, &quot;port&quot; =&gt; 4567 ),
- ( &quot;host&quot; =&gt; &quot;127.0.0.1&quot;, &quot;port&quot; =&gt; 4568 )
- )
- )
-}</code></pre>
-</li>
-
-<li>
-<p>Start thin and your application. I have a rake script so I can just call &#8220;rake start&#8221; rather than typing this in.</p>
-
-<pre><code>thin -s 2 -C config.yml -R config.ru start</code></pre>
-</li>
-</ol>
-
-<p>You&#8217;re done! Go to mydomain.com/ and see the result! Everything should be setup now, check it out at the domain you setup in your lighttpd.conf file.</p>
-
-<p><em>Variation</em> - nginx via proxy - The same approach to proxying can be applied to the nginx web server</p>
-
-<pre><code>upstream www_mydomain_com {
- server 127.0.0.1:5000;
- server 127.0.0.1:5001;
-}
-
-server {
- listen www.mydomain.com:80
- server_name www.mydomain.com live;
- access_log /path/to/logfile.log
-
- location / {
- proxy_pass http://www_mydomain_com;
- }
-
-}</code></pre>
-
-<p><em>Variation</em> - More Thin instances - To add more thin instances, change the <code>-s 2</code> parameter on the thin start command to be how ever many servers you want. Then be sure lighttpd proxies to all of them by adding more lines to the proxy statements. Then restart lighttpd and everything should come up as expected.</p>
-
-<h2 id='deployment_passenger'>Passenger (mod rails)</h2>
-
-<p>Hate deployment via FastCGI? You&#8217;re not alone. But guess what, Passenger supports Rack; and this book tells you how to get it all going.</p>
-
-<p>You can find additional documentation at the Passenger Github repository.</p>
-
-<ol>
-<li>
-<p>Setting up the account in the Dreamhost interface</p>
-
-<pre><code>Domains -&gt; Manage Domains -&gt; Edit (web hosting column)
-Enable &#39;Ruby on Rails Passenger (mod_rails)&#39;
-Add the public directory to the web directory box. So if you were using &#39;rails.com&#39;, it would change to &#39;rails.com/public&#39;
-Save your changes</code></pre>
-</li>
-
-<li>
-<p>Creating the directory structure</p>
-
-<pre><code>domain.com/
-domain.com/tmp
-domain.com/public
-# a vendored version of sinatra - not necessary if you use the gem
-domain.com/sinatra</code></pre>
-</li>
-
-<li>
-<p>Creating the &#8220;Rackup file&#8221; (rack configuration file) <code>config.ru</code> &#8211; the <code>require &#39;app&#39;</code> line should require the actual Sinatra app you have written.</p>
-
-<pre><code>## Passenger should set RACK_ENV for Sinatra
-
-require &#39;app&#39;
-
-run Sinatra::Application</code></pre>
-</li>
-
-<li>
-<p>A very simple Sinatra application</p>
-
-<pre><code># this is test.rb referred to above
-get &#39;/&#39; do
- &quot;Worked on dreamhost&quot;
-end
-
-get &#39;/foo/:bar&#39; do
- &quot;You asked for foo/#{params[:bar]}&quot;
-end</code></pre>
-</li>
-</ol>
-
-<p>And that&#8217;s all there is to it! Once it&#8217;s all setup, point your browser at your domain, and you should see a &#8216;Worked on Dreamhost&#8217; page. To restart the application after making changes, you need to run <code>touch tmp/restart.txt</code>.</p>
-
-<p>Please note that currently passenger 2.0.3 has a bug where it can cause Sinatra to not find the view directory. In that case, add <code>:views =&gt; &#39;/path/to/views/&#39;</code> to the Sinatra options in your Rackup file.</p>
-
-<p>You may encounter the dreaded &#8220;Ruby (Rack) application could not be started&#8221; error with this message &#8220;can&#8217;t activate rack (&gt;= 0.9.1, &lt; 1.0, runtime), already activated rack-0.4.0&#8221;. This happens because DreamHost has version 0.4.0 installed, when recent versions of Sinatra require more recent versions of Rack. The solution is to explicitly require the rack and sinatra gems in your config.ru. Add the following two lines to the start of your config.ru file:</p>
-
-<pre><code> require &#39;/home/USERNAME/.gem/ruby/1.8/gems/rack-VERSION-OF-RACK-GEM-YOU-HAVE-INSTALLELD/lib/rack.rb&#39;
- require &#39;/home/USERNAME/.gem/ruby/1.8/gems/sinatra-VERSION-OF-SINATRA-GEM-YOU-HAVE-INSTALLELD/lib/sinatra.rb&#39;</code></pre>
-
-<h2 id='deployment_fastcgi'>FastCGI</h2>
-
-<p>The standard method for deployment is to use Thin or Mongrel, and have a reverse proxy (lighttpd, nginx, or even Apache) point to your bundle of servers.</p>
-
-<p>But that isn&#8217;t always possible. Cheaper shared hosting (like Dreamhost) won&#8217;t let you run Thin or Mongrel, or setup reverse proxies (at least on the default shared plan).</p>
-
-<p>Luckily, Rack supports various connectors, including CGI and FastCGI. Unluckily for us, FastCGI doesn&#8217;t quite work with the current Sinatra release without some tweaking.</p>
-
-<h3 id='deployment_with_sinatra_version_09'>Deployment with Sinatra version 0.9</h3>
-
-<p>From version 9.0 Sinatra requires Rack 0.9.1, however FastCGI wrapper from this version seems not working well with Sinatra unless you define your application as a subclass of Sinatra::Application class and run this application directly as a Rack application.</p>
-
-<p>Steps to deploy via FastCGI:</p>
-
-<ul>
-<li>htaccess</li>
-
-<li>subclass your application as Sinatra::Application</li>
-
-<li>dispatch.fcgi</li>
-</ul>
-
-<ol>
-<li>
-<p>.htaccess</p>
-
-<pre><code> RewriteEngine on
-
- AddHandler fastcgi-script .fcgi
- Options +FollowSymLinks +ExecCGI
-
- RewriteRule ^(.*)$ dispatch.fcgi [QSA,L]</code></pre>
-</li>
-
-<li>
-<p>Subclass your application as Sinatra::Application</p>
-
-<pre><code> # my_sinatra_app.rb
- class MySinatraApp &lt; Sinatra::Application
- # your sinatra application definitions
- end</code></pre>
-</li>
-
-<li>
-<p>dispatch.fcgi - Run this application directly as a Rack application</p>
-
-<pre><code> #!/usr/local/bin/ruby
-
- require &#39;rubygems&#39;
- require &#39;rack&#39;
-
- fastcgi_log = File.open(&quot;fastcgi.log&quot;, &quot;a&quot;)
- STDOUT.reopen fastcgi_log
- STDERR.reopen fastcgi_log
- STDOUT.sync = true
-
- module Rack
- class Request
- def path_info
- @env[&quot;REDIRECT_URL&quot;].to_s
- end
- def path_info=(s)
- @env[&quot;REDIRECT_URL&quot;] = s.to_s
- end
- end
- end
-
- load &#39;my\_sinatra\_app.rb&#39;
-
- builder = Rack::Builder.new do
- map &#39;/&#39; do
- run MySinatraApp.new
- end
- end
-
- Rack::Handler::FastCGI.run(builder)</code></pre>
-</li>
-</ol>
-
-<h3 id='deployment_with_sinatra_version__03'>Deployment with Sinatra version &lt;= 0.3</h3>
-
-<p>In version 0.3 to get a simple &#8216;hello world&#8217; Sinatra application up and running via FastCGI, you have to pulling down the current Sinatra code, and hacking at it a bit. Don&#8217;t worry though, it only requires commenting out a few lines, and tweaking another.</p>
-
-<p>Steps to deploy:</p>
-
-<ul>
-<li>.htaccess</li>
-
-<li>dispatch.fcgi</li>
-
-<li>Tweaked sinatra.rb</li>
-</ul>
-
-<ol>
-<li>
-<p>.htaccess RewriteEngine on</p>
-
-<pre><code>AddHandler fastcgi-script .fcgi
-Options +FollowSymLinks +ExecCGI
-
-RewriteRule ^(.*)$ dispatch.fcgi [QSA,L]</code></pre>
-</li>
-
-<li>
-<p>dispatch.fcgi</p>
-
-<pre><code>#!/usr/bin/ruby
-
-require &#39;rubygems&#39;
-require &#39;sinatra/lib/sinatra&#39;
-
-fastcgi_log = File.open(&quot;fastcgi.log&quot;, &quot;a&quot;)
-STDOUT.reopen fastcgi_log
-STDERR.reopen fastcgi_log
-STDOUT.sync = true
-
-set :logging, false
-set :server, &quot;FastCGI&quot;
-
-module Rack
- class Request
- def path_info
- @env[&quot;REDIRECT_URL&quot;].to_s
- end
- def path_info=(s)
- @env[&quot;REDIRECT_URL&quot;] = s.to_s
- end
- end
-end
-
-load &#39;app.rb&#39;</code></pre>
-</li>
-
-<li>
-<p>sinatra.rb - Replace this function with the new version here (commenting out the <code>puts</code> lines)</p>
-
-<pre><code>def run
- begin
- #puts &quot;== Sinatra has taken the stage on port #{port} for #{env} with backup by #{server.name}&quot;
- require &#39;pp&#39;
- server.run(application) do |server|
- trap(:INT) do
- server.stop
- #puts &quot;\n== Sinatra has ended his set (crowd applauds)&quot;
- end
- end
- rescue Errno::EADDRINUSE =&gt; e
- #puts &quot;== Someone is already performing on port #{port}!&quot;
- end
-end</code></pre>
-</li>
-</ol>
-<hr />
-<h1 id='contributing'>Contributing</h1>
-
-<h2 id='how_can_i_clone_the_sinatra_repository'>How can I clone the Sinatra repository?</h2>
-
-<p>First of all, you&#8217;ll need the <a href='http://git.or.cz'>Git</a> version control system. <a href='http://git.or.cz'>Git</a> is available for all major platforms:</p>
-
-<ul>
-<li><a href='http://code.google.com/p/msysgit/'>Windows</a></li>
-
-<li><a href='http://code.google.com/p/git-osx-installer/'>Mac OS X</a></li>
-
-<li>Linux and BSD users can usually acquire <a href='http://git.or.cz'>Git</a> through their Package Management System, e.g. <code>apt-get install git-core</code> on Debian systems.</li>
-</ul>
-
-<p>After that, cloning the Sinatra repository is as easy as typing the following into your command line:</p>
-
-<pre><code>git clone git://github.com/sinatra/sinatra.git</code></pre>
-
-<h2 id='how_to_create_a_patch'>How to create a patch?</h2>
-
-<h2 id='how_to_get_that_patch_into_the_official_sinatra'>How to get that patch into the official Sinatra?</h2>

0 comments on commit 7d7770b

Please sign in to comment.
Something went wrong with that request. Please try again.