Sinatra

The code you changed will not take effect until you restart the server. Please restart the server every time you change or use a code reloader like rerun or rack-unreloader. Table of Contents Sinatra Table of Contents Routes Conditions Return Values Custom Route Matchers Static Files Views / Templates Literal Templates Available Template Languages Haml Templates Erb Templates Builder Templates Nokogiri Templates Sass Templates Scss Templates Liquid Templates Markdown Templates RDoc Templates AsciiDoc Templates Markaby Templates RABL Templates Slim Templates Yajl Templates Accessing Variables in Templates Templates with yield and nested layouts Inline Templates Named Templates Associating File Extensions Adding Your Own Template Engine Using Custom Logic for Template Lookup Filters Helpers Using Sessions Session Secret Security Session Config Choosing Your Own Session Middleware Halting Passing Triggering Another Route Setting Body, Status Code, and Headers Streaming Responses Logging Mime Types Generating URLs Browser Redirect Cache Control Sending Files Accessing the Request Object Attachments Dealing with Date and Time Looking Up Template Files Configuration Configuring attack protection Available Settings Lifecycle Events Environments Error Handling Not Found Error Rack Middleware Testing Sinatra::Base - Middleware, Libraries, and Modular Apps Modular vs. Classic Style Serving a Modular Application Using a Classic Style Application with a config.ru When to use a config.ru? Using Sinatra as Middleware Dynamic Application Creation Scopes and Binding Application/Class Scope Request/Instance Scope Delegation Scope Command Line Multi-threading Requirement The Bleeding Edge With Bundler Versioning Further Reading Routes are matched in the order they are defined. The first route that matches the request is invoked. By the way, unless you disable the path traversal attack protection (see below), the request path might be modified before matching against your routes. It looks like a condition, but it isn't one! These options will be merged into the global :mustermann opts hash described below. You can also use the stream helper method (described below) to reduce boilerplate and embed the streaming logic in the route. As shown above, Sinatra ships with built-in support for using String patterns and regular expressions as route matches. However, it does not stop there. You can easily define your own matchers: Static files are served from the ./public directory. You can specify a different location by setting the :public folder option: Use the :static cache control setting (see below) to add Cache-Control header info. By default, Sinatra serves static files from the public/ folder without running middleware or filters. To add custom headers (e.g, for CORS or caching), use the :static headers setting: Each template language is exposed via its own rendering method. These methods simply return a string: Options passed to the render method override options set via set . Scope to render template under. Defaults to the application instance. If you change this, instance variables and helper methods will not be available. Template engine to use for rendering the layout. Useful for languages that do not support layouts otherwise. Defaults to the engine used for the template. Example: set :rdoc, :layout engine = :erb Special options only used for rendering the layout. Example: set :rdoc, :layout options = { :views = 'views/layouts' } Templates are assumed to be located directly under the ./views directory. To use a different views directory: One important thing to remember is that you always have to reference templates with symbols, even if they're in a subdirectory (in this case, use: :'subdir/template' or 'subdir/template'.to sym ). You must use a symbol because otherwise rendering methods will render any strings passed to them directly. Renders the template string. You can optionally specify :path and :line for a clearer back