scorched 0.7 → 0.8

data/docs/02_fundamentals/03_routing.md

@@ -1,33 +1,35 @@
 Routing
 =======
 
-When Scorched receives a request, the first thing it does is iterate over it's internal mapping hash, looking for the any URL pattern that matches the current URL. If it finds an appropriate match, it invokes the ``call`` method on the target defined for that mapping, unless the target is a ``Proc``, in which case it's invoked via ``instance_exec`` to run it within the context of the controller instance.
+When Scorched receives a request, the first thing it does is iterate over it's internal mapping hash, looking for the any URL pattern that matches the current URL. If it finds an appropriate match, it invokes the `call` method on the target defined for that mapping, unless the target is a `Proc`, in which case it's invoked via `instance_exec` to run it within the context of the controller instance.
 
-Mappings can be defined manually using the ``map`` class method, also aliased as ``<<``. Besides the required URL pattern and target elements, a mapping can also define a priority, and one or more conditions. The example below demonstrates the use of all of them.
+Mappings can be defined manually using the `map` class method, also aliased as `<<`. Besides the required URL pattern and target elements, a mapping can also define a priority, and one or more conditions. The example below demonstrates the use of all of them.
 
-    # ruby
-    map pattern: '/', priority: -99, conditions: {methods: ['POST', 'PUT', 'DELETE']}, target: proc { |env|
-      [200, {}, 'Bugger off']
-    }
+```ruby
+map pattern: '/', priority: -99, conditions: {methods: ['POST', 'PUT', 'DELETE']}, target: proc { |env|
+  [200, {}, 'Bugger off']
+}
+```
 
 The position the new mapping is inserted into the mapping hash is determined by it's priority, and the priority of the mappings already defined. This avoids re-sorting the mapping hash every time it's added to. This isn't a performance consideration, but is required to maintain the natural insert order of the mappings which have identical priorities (such as the default 0).
 
-A ``mapping`` method is also provided as means to access all defined mappings on a controller, but it should be considered read-only for the reasons just stated.
+A `mapping` method is also provided as means to access all defined mappings on a controller, but it should be considered read-only for the reasons just stated.
 
 Route Helpers
 -------------
 Adding mappings manually can be a little verbose and painful, which is why Scorched includes a bunch of route helpers which are used in most code examples.
 
-The main route helper which all others delegate to, is the ``route`` class method. Here's what it looks like in both it's simple and advance form:
+The main route helper which all others delegate to, is the `route` class method. Here's what it looks like in both it's simple and advance form:
 
-    # ruby
-    route '/' do
-      'Well hello there'
-    end
-    
-    route '/*', 5, methods: ['POST', 'PUT', 'DELETE'] do |capture|
-      "Hmm trying to change #{capture} I see"
-    end
+```ruby
+route '/' do
+  'Well hello there'
+end
+
+route '/*', 5, methods: ['POST', 'PUT', 'DELETE'] do |capture|
+  "Hmm trying to change #{capture} I see"
+end
+```
 
 You can see pretty clearly how these examples correspond to the pattern, priority, conditions and target options of a manual mapping. The pattern, priority and conditions behave exactly as they do for a manual mapping, with a couple of exceptions.
 
@@ -35,12 +37,12 @@ The first exception is that the pattern must match to the end of the request pat
 
 The other more notable exception is in how the given block is treated. The block given to the route helper is wrapped in another proc. The wrapping proc does a couple of things. It first sends all the captures in the url pattern as argument to the given block, this is shown in the example above. The other thing it does is takes care of assigning the return value to the body of the response.
 
-In the latter of the two examples above, a ``:methods`` condition defines what methods the route is intended to process. The first example has no such condition, so it accepts all HTTP methods. Typically however, a route will handle a single HTTP method, which is why Scorched also provides the convenience helpers: ``get``, ``post``, ``put``, ``delete``, ``head``, ``options``, and ``patch``. These methods automatically define the corresponding ``:method`` condition, with the ``get`` helper also including ``head`` as an accepted HTTP method.
+In the latter of the two examples above, a `:methods` condition defines what methods the route is intended to process. The first example has no such condition, so it accepts all HTTP methods. Typically however, a route will handle a single HTTP method, which is why Scorched also provides the convenience helpers: `get`, `post`, `put`, `delete`, `head`, `options`, and `patch`. These methods automatically define the corresponding `:method` condition, with the `get` helper also including `head` as an accepted HTTP method.
 
 Pattern Matching
 ----------------
 All patterns attempt to match the remaining unmatched portion of the _request path_; the _request path_ being Rack's
-``path_info`` request variable. The unmatched path will always begin with a forward slash if the previously matched portion of the path ended immediately before, or included as the last character, a forward slash. As an example, if the request was to "/article/21", then both "/article/" => "/21" and "/article" => "/21" would match.
+`path_info` request variable. The unmatched path will always begin with a forward slash if the previously matched portion of the path ended immediately before, or included as the last character, a forward slash. As an example, if the request was to "/article/21", then both "/article/" => "/21" and "/article" => "/21" would match.
 
 All patterns must match from the beginning of the path. So even though the pattern "article" would match "/article/21", it wouldn't count as a match because the match didn't start at a non-zero offset.
 
@@ -55,7 +57,7 @@ String patterns are compiled into Regexp patterns corresponding to the following
 * `**` - Matches all characters including the forward slash.
 * `:param` - Same as `*` except the capture is named to whatever the string following the single-colon is.
 * `::param` - Same as `**` except the capture is named to whatever the string following the double-colon is.
-* `$` - If placed at the end of a pattern, the pattern only matches if it matches the entire path. For patterns defined using the route helpers, e.g. ``Controller.route``, ``Controller.get``, this is implied. 
+* `$` - If placed at the end of a pattern, the pattern only matches if it matches the entire path. For patterns defined using the route helpers, e.g. `Controller.route`, `Controller.get`, this is implied. 
 
 ###Regex Patterns
 Regex patterns offer more power and flexibility than string patterns (naturally). The rules for Regex patterns are identical to String patterns, e.g. they must match from the beginning of the path, etc. 
@@ -63,30 +65,31 @@ Regex patterns offer more power and flexibility than string patterns (naturally)
 
 Conditions
 ----------
-Conditions are essentially just pre-requisites that must be met before a mapping is invoked to handle the current request. They're implemented as ``Proc`` objects which take a single argument, and return true if the condition is satisfied, or false otherwise. Scorched comes with a number of pre-defined conditions included, many of which are provided by _rack-accept_ - one of the few dependancies of Scorched.
-
-* ``:charset`` - Character sets accepted by the client.
-* ``:encoding`` - Encodings accepted by the client.
-* ``:host`` - The host name (i.e. domain name) used in the request.
-* ``:language`` - Languages accepted by the client.
-* ``:media_type`` - Media types (i.e. content types) accepted by the client.
-* ``:methods`` - The request method used, e.g. GET, POST, PUT, ...
-* ``:user_agent`` - The user agent string provided with the request. Takes a Regexp or String.
-* ``:status`` - The response status of the request. Intended for use by _after_ filters.
-
-Like configuration options, conditions are implemented using the ``Scorched::Options`` class, so they're inherited and be overridable by child classes. You may easily add your own conditions as the example below demonstrates.
-
-    # ruby
-    condition[:has_permission] = proc { |v|
-      user.has_permission == v
-    }
-    
-    get '/', has_permission: true do
-      'Welcome'
-    end
-    
-    get '/', has_permission: false do
-      'Forbidden'
-    end
-
-Each of the built-in conditions can take a single value, or an array of values, with the exception of the ``:host`` and ``:user_agent`` conditions which support Regexp patterns.
+Conditions are essentially just pre-requisites that must be met before a mapping is invoked to handle the current request. They're implemented as `Proc` objects which take a single argument, and return true if the condition is satisfied, or false otherwise. Scorched comes with a number of pre-defined conditions included, many of which are provided by _rack-accept_ - one of the few dependancies of Scorched.
+
+* `:charset` - Character sets accepted by the client.
+* `:encoding` - Encodings accepted by the client.
+* `:host` - The host name (i.e. domain name) used in the request.
+* `:language` - Languages accepted by the client.
+* `:media_type` - Media types (i.e. content types) accepted by the client.
+* `:methods` - The request method used, e.g. GET, POST, PUT, ...
+* `:user_agent` - The user agent string provided with the request. Takes a Regexp or String.
+* `:status` - The response status of the request. Intended for use by _after_ filters.
+
+Like configuration options, conditions are implemented using the `Scorched::Options` class, so they're inherited and be overridable by child classes. You may easily add your own conditions as the example below demonstrates.
+
+```ruby
+condition[:has_permission] = proc { |v|
+  user.has_permission == v
+}
+
+get '/', has_permission: true do
+  'Welcome'
+end
+
+get '/', has_permission: false do
+  'Forbidden'
+end
+```
+
+Each of the built-in conditions can take a single value, or an array of values, with the exception of the `:host` and `:user_agent` conditions which support Regexp patterns.

data/docs/02_fundamentals/04_requests_and_responses.md

@@ -1,30 +1,35 @@
 Requests and Responses
 ======================
-One of the first things a controller does when it instantiates itself, is make the Rack environment hash accessible via the ``env`` helper, as well as make available a ``Scorched::Request`` and ``Scorched::Response`` object under the respective ``request`` and ``response`` methods.
+One of the first things a controller does when it instantiates itself, is make the Rack environment hash accessible via the `env` helper, as well as make available a `Scorched::Request` and `Scorched::Response` object under the respective `request` and `response` methods.
 
-The ``Scorched::Request`` and ``Scorched::Response`` classes are children of the corresponding _Rack_ request and response classes, with a little extra functionality tacked on.
+The `Scorched::Request` and `Scorched::Response` classes are children of the corresponding _Rack_ request and response classes, with a little extra functionality tacked on.
 
 The _request_ object makes accessible all the information associated with the current request, such as the GET and POST data, server and environment information, request headers, and so on. The _response_ is much the same, but in reverse. You'll use the _response_ object to set response headers and manipulate the body of the response.
 
-Refer to the _Rack_ documentation for more information on the ``Rack::Request`` and ``Rack::Response`` classes.
+Refer to the _Rack_ documentation for more information on the `Rack::Request` and `Rack::Response` classes.
 
 
 Scorched Extras
 ---------------
-As mentioned, Scorched tacks a few extras onto it's ``Scorched::Request`` and ``Scorched::Response`` classes. Most of these extras were added as a requirement of the Scorched controller, but they're just as useful to other developers.
+As mentioned, Scorched tacks a few extras onto it's `Scorched::Request` and `Scorched::Response` classes. Most of these extras were added as a requirement of the Scorched controller, but they're just as useful to other developers.
 
-Refer to the generated API documentation for ``Scorched::Request`` and ``Scorched::Response``.
+Refer to the generated API documentation for `Scorched::Request` and `Scorched::Response`.
 
 
 Halting Requests
 ----------------
-There may be instances we're you want to shortcut out-of processing the current request. The ``halt`` method allows you to do this, though it's worth clarifying its behaviour.
+There may be instances we're you want to shortcut out-of processing the current request. The `halt` method allows you to do this, though it's worth clarifying its behaviour.
 
-When ``halt`` is called within a route, it simply exists out of that route, and begins processing any _after_ filters. Halt can also be used within a _before_ or _after_ filter, in which case any remaining filters in the current controller are skipped.
+When `halt` is called within a route, it simply exists out of that route, and begins processing any _after_ filters. Halt can also be used within a _before_ or _after_ filter, in which case any remaining filters in the current controller are skipped.
 
-Calls to ``halt`` don't propagate up the controller chain. They're local to the controller. A call to ``halt`` is equivalent to doing a ``throw :halt``. Calling ``halt`` is often preferred though because as well as being shorter, it can take an optional argument to set the response status, which is something you typically want to do when halting a request.
+Calls to `halt` don't propagate up the controller chain. They're local to the controller. A call to `halt` is equivalent to doing a `throw :halt`. Calling `halt` is often preferred though because as well as being shorter, it can take an optional argument to set the response status, which is something you typically want to do when halting a request.
+
+
+Passing Requests
+----------------
+A route may _pass_ a request to the next matching route. _passing_ is very similar to halting, except an opportunity is given to other matching routes to fulfil the request. This is implemented as a throw/catch mechanism, much the same as `halt`. You can do a `throw :pass` manually, or use the helper method `pass`.
 
 
 Redirections
 ------------
-A common requirement of many applications is to redirect requests to another URL based on some kind of condition. Scorched offers the very simple ``redirect`` method which takes one argument - the URL to redirect to. Like ``halt`` it's mostly a convenience method. It sets the _Location_ header of the response before halting the request.
+A common requirement of many applications is to redirect requests to another URL based on some kind of condition. Scorched offers the very simple `redirect` method which takes one argument - the URL to redirect to. Like `halt` it's mostly a convenience method. It sets the _Location_ header of the response before halting the request.

data/docs/02_fundamentals/05_filters.md

@@ -1,6 +1,6 @@
 Filters
 =======
-Filters serve as a handy place to put functionality and behaviour that's common to a set of routes, or for that matter, a whole website or application. Filters are executed in the context of the controller; the same context as routes. Filters are also inheritable, meaning sub-classes inherit the filters of their parent - this inheritance is enabled through the use of the ``Scorched::Collection`` class, and is implemented such that each filter will only run once per-request.
+Filters serve as a handy place to put functionality and behaviour that's common to a set of routes, or for that matter, a whole website or application. Filters are executed in the context of the controller; the same context as routes. Filters are also inheritable, meaning sub-classes inherit the filters of their parent - this inheritance is enabled through the use of the `Scorched::Collection` class, and is implemented such that each filter will only run once per-request.
 
 There are currently two types of filter in Scorched, both of which are documented below.
 
@@ -9,24 +9,27 @@ Before and After Filters
 ------------------------
 Before and After filters allow pre- and post-processing of requests. They are executed before and after each request, respectively.
 
-    # ruby
-    before do
-      raise Error, "Must be logged in to access this site" unless session[:logged_in] == true
-    end
+```ruby
+before do
+  raise Error, "Must be logged in to access this site" unless session[:logged_in] == true
+end
+```
 
 Like routes, filters can have conditions defined on them, for example:
 
-    # ruby
-    after media_type: 'application/json' do
-      response.body.to_json!
-    end
+```ruby
+after media_type: 'application/json' do
+  response.body.to_json!
+end
+```
 
 Before and after filters run even if no route within the controller matches. This makes them suitable for handling 404 errors for example.
 
-    # ruby
-    after status: 404 do
-      response.body = render(:not_found)
-    end
+```ruby
+after status: 404 do
+  response.body = render(:not_found)
+end
+```
 
 Your imagination is the only limitation.
 
@@ -39,7 +42,8 @@ Error filters can handle exceptions raised from within the request target, as we
 
 Error filters can target only specific types of exception class, in much the same way as a typical Ruby rescue block.
 
-    # ruby
-    error PermissionError do |e|
-      flash[:error] = "You do not have the appropriate permission to perform that action: #{e.message}"
-    end
+```ruby
+error PermissionError do |e|
+  flash[:error] = "You do not have the appropriate permission to perform that action: #{e.message}"
+end
+```

data/docs/02_fundamentals/06_middleware.md

@@ -3,16 +3,17 @@ Middleware
 
 While middleware can be added in your _rackup_ file to wrap your Scorched application, it can be more desirable to add the middleware at the controller level. Scorched itself requires this as it needs to include a set of Rack middleware out-of-the-box. Developers can't be expected to manually add these to their rackup file for every Scorched application.
 
-Like _filters_, middleware is inheritable thanks to it's use of the ``Scorched::Collection`` class. Also like _filters_, middleware proc's are only run once per request, which prevents unintended double-loading of middleware.
+Like _filters_, middleware is inheritable thanks to it's use of the `Scorched::Collection` class. Also like _filters_, middleware proc's are only run once per request, which prevents unintended double-loading of middleware.
 
-Adding middleware to a Scorched controller involves pushing a proc onto the end of the middleware collection, accessible via the ``middleware`` accessor method. The given proc is ``instance_exec``'d in the context of a Rack builder object, and so can be used for more than just loading middleware. 
+Adding middleware to a Scorched controller involves pushing a proc onto the end of the middleware collection, accessible via the `middleware` accessor method. The given proc is `instance_exec`'d in the context of a Rack builder object, and so can be used for more than just loading middleware. 
 
-    # ruby
-    middleware << proc do
-      use Rack::Session::Cookie, secret: 'blah'
-      # Stolen from Rack's own documentation...
-      map "/lobster" do
-        use Rack::Lint
-        run Rack::Lobster.new
-      end
-    end
+```ruby
+middleware << proc do
+  use Rack::Session::Cookie, secret: 'blah'
+  # Stolen from Rack's own documentation...
+  map "/lobster" do
+    use Rack::Lint
+    run Rack::Lobster.new
+  end
+end
+```

data/docs/02_fundamentals/07_request_and_session_data.md

@@ -3,87 +3,93 @@ Request and Session Data
 
 GET and POST Data
 -----------------
-Many ruby frameworks provide helpers for accessing GET and POST data via some kind of generic accessor, such as a ``params`` method, but Rack already provides this functionality out of the box, and more.
-
-    # ruby
-    post '/' do
-      request.GET['view'] # Key/value pairs submitted in the query string of the URL.
-      request.POST['username'] # Key/value pairs submitted in the payload of a POST request.
-      request.params[:username] # A merged hash of GET and POST data.
-      request[:username] # Shortcut to merged hash of GET and POST data.
-    end
+Many ruby frameworks provide helpers for accessing GET and POST data via some kind of generic accessor, such as a `params` method, but Rack already provides this functionality out of the box, and more.
+
+```ruby
+post '/' do
+  request.GET['view'] # Key/value pairs submitted in the query string of the URL.
+  request.POST['username'] # Key/value pairs submitted in the payload of a POST request.
+  request.params[:username] # A merged hash of GET and POST data.
+  request[:username] # Shortcut to merged hash of GET and POST data.
+end
+```
 
 Uploaded files are also accessible as ordinary fields, except the associated value is a hash of properties, instead of a string. An example of an application that accepts file uploads is included in the "examples" directory of the Scorched git repository.
 
 Cookies
 -------
-While Rack provides a relatively simple means of setting, retrieving and deleting cookies, Scorched aggregates those three actions into a single method, ``cookie``, for the sake of brevity and simplicity.
+While Rack provides a relatively simple means of setting, retrieving and deleting cookies, Scorched aggregates those three actions into a single method, `cookie`, for the sake of brevity and simplicity.
 
-    # ruby
-    def '/' do
-      cookie :previous_page # Retrieves the cookie.
-      cookie :previous_page, '/search' # Sets the cookie
-      cookie :previous_page, nil # Deletes the cookies
-    end
+```ruby
+def '/' do
+  cookie :previous_page # Retrieves the cookie.
+  cookie :previous_page, '/search' # Sets the cookie
+  cookie :previous_page, nil # Deletes the cookies
+end
+```
    
-For each of the above lines, the corresponding Rack methods are called, e.g. ``Rack::Requeste#cookies``, ``Rack::Response#set_cookie`` and ``Rack::Response#delete_cookie``. The values for setting and deleting a cookie can also be a hash, like ``set_cookie`` and ``delete_cookie`` can take directly. Deleting still works when a Hash is provided, as long as the ``value`` property is nil.
+For each of the above lines, the corresponding Rack methods are called, e.g. `Rack::Requeste#cookies`, `Rack::Response#set_cookie` and `Rack::Response#delete_cookie`. The values for setting and deleting a cookie can also be a hash, like `set_cookie` and `delete_cookie` can take directly. Deleting still works when a Hash is provided, as long as the `value` property is nil.
 
-    # ruby
-    def '/' do
-      cookie :view, path: '/account', value: 'datasheet' # Sets the cookie
-      cookie :view, path: '/account', value: nil # Deletes the cookie
-    end
+```ruby
+def '/' do
+  cookie :view, path: '/account', value: 'datasheet' # Sets the cookie
+  cookie :view, path: '/account', value: nil # Deletes the cookie
+end
+```
 
 
 Sessions
 --------
-Sessions are completely handled by Rack. For conveniance, a ``session`` helper is provided. This merely acts as an alias to ``request['rack.session']`` however. It was raise an exception if called without any Rack session middleware loaded, such as ``Rack::Session::Cookie``.
-
-    # ruby
-    class App < Scorched::Controller
-      middleware << proc {
-        use Rack::Session::Cookie, secret: 'blah'
-      }
-      
-      get '/' do
-        session['logged_in'] ? 'You're currently logged in.' : 'Please login.'
-      end
-    end
+Sessions are completely handled by Rack. For conveniance, a `session` helper is provided. This merely acts as an alias to `request['rack.session']` however. It was raise an exception if called without any Rack session middleware loaded, such as `Rack::Session::Cookie`.
+
+```ruby
+class App < Scorched::Controller
+  middleware << proc {
+    use Rack::Session::Cookie, secret: 'blah'
+  }
+  
+  get '/' do
+    session['logged_in'] ? 'You're currently logged in.' : 'Please login.'
+  end
+end
+```
 
 ###Flash
 A common requirement for websites, and especially web applications, is to provide a message on the next page load corresponding to an action that a user just performed. A common framework idiom that Scorched happily implements are flash session variables - special session data that lives for only a single page load.
 
 This isn't as trivial to implement as it may sound at a glance, which is why Scorched provides this helper.
 
-    # ruby
-    get '/' do
-      "<span class="success">#{flash[:success]}</span>" if flash[:success]
-    end
-    
-    post '/login' do
-      flash[:success] = 'Logged in successfully.'
-    end
+```ruby
+get '/' do
+  "<span class="success">#{flash[:success]}</span>" if flash[:success]
+end
+
+post '/login' do
+  flash[:success] = 'Logged in successfully.'
+end
+```
 
 The flash helper allows multiple sets of flash session data to be stored under different names. Because of how flash sessions are implemented, they're only deleted on the next page load if that particular flash data set is accessed. These properties of flash sessions can satisfy some interesting use cases. Here's a very uninteresting example:
 
-    # ruby
-    class App < Scorched::Controller
-      get '/' do
-        "<span class="success">#{flash[:success]}</span>" if flash[:success]
-      end
-    
-      post '/login' do
-        flash[:success] = 'Logged in successfully.'
-        if user.membership_type == 'vip' && user.membership_expiry < 5
-          flash(:vip)[:warning] = 'Your VIP membership is about to expire, please renew it.'
-        end
-      end
-      
-      controller pattern: '/vip' do
-        get '/' do
-          "<span class="warning">#{flash(:vip)[:warning]}</span>" if flash(:vip)[:warning]
-        end
-      end
+```ruby
+class App < Scorched::Controller
+  get '/' do
+    "<span class="success">#{flash[:success]}</span>" if flash[:success]
+  end
+
+  post '/login' do
+    flash[:success] = 'Logged in successfully.'
+    if user.membership_type == 'vip' && user.membership_expiry < 5
+      flash(:vip)[:warning] = 'Your VIP membership is about to expire, please renew it.'
+    end
+  end
+  
+  controller '/vip' do
+    get '/' do
+      "<span class="warning">#{flash(:vip)[:warning]}</span>" if flash(:vip)[:warning]
     end
+  end
+end
+```
 
-In the rather contrived example above, when a VIP user logs in, a message is generated and stored as a flash session variable in the ``:vip`` flash data set. Because the ``:vip`` flash data set isn't accessed on the main page, it lives on until it's finally re-accessed on the VIP page.
+In the rather contrived example above, when a VIP user logs in, a message is generated and stored as a flash session variable in the `:vip` flash data set. Because the `:vip` flash data set isn't accessed on the main page, it lives on until it's finally re-accessed on the VIP page.

data/docs/02_fundamentals/08_views.md

@@ -1,22 +1,22 @@
 Views
 =====
 
-Scorched uses Tilt to render templates in various supported formats. Because of this, views have been implemented as a single method, ``render``.
+Scorched uses Tilt to render templates in various supported formats. Because of this, views have been implemented as a single method, `render`.
 
-``render`` can take a file path or a string as the template. If a symbol is given, it assumes it's a file path, were as a string is assumed to be the template markup. ``render`` can also takes a set of options.
+`render` can take a file path or a string as the template. If a symbol is given, it assumes it's a file path, were as a string is assumed to be the template markup. `render` can also takes a set of options.
 
-* ``:dir`` - The directory containing the views. This can be absolute or relative to the current working directory.
-* ``:layout`` - The template to render _around_ the view.
-* ``:engine`` - The template engine to use if it can't be derived from the file name. This is always required for string templates. Can be any string or symbol that Tilt recognises, e.g :erb, :haml, :sass, etc.
+* `:dir` - The directory containing the views. This can be absolute or relative to the current working directory.
+* `:layout` - The template to render _around_ the view.
+* `:engine` - The template engine to use if it can't be derived from the file name. This is always required for string templates. Can be any string or symbol that Tilt recognises, e.g :erb, :haml, :sass, etc.
 
-Any unrecognised options are passed through to Tilt and the corresponding rendering engine. A common example being the ``:locals`` option, used to set local variables made available within the scope of the view.
+Any unrecognised options are passed through to Tilt and the corresponding rendering engine. A common example being the `:locals` option, used to set local variables made available within the scope of the view.
 
-Finally, ``render`` takes an optional block to be _yielded_ within the view being rendered, if supported by the rendering engine. Layout's use this feature.
+Finally, `render` takes an optional block to be _yielded_ within the view being rendered, if supported by the rendering engine. Layout's use this feature.
 
 Layouts
 -------
-When a layout is given, a subsequent call to ``render`` is made, with the rendered result of the main template given as the block to be yielded. The defined ``:layout`` is provided as the first argument on the sub-sequent call to ``render``, so the same rules apply. Layouts inherit the options of the main template being rendered.
+When a layout is given, a subsequent call to `render` is made, with the rendered result of the main template given as the block to be yielded. The defined `:layout` is provided as the first argument on the sub-sequent call to `render`, so the same rules apply. Layouts inherit the options of the main template being rendered.
 
 Partials
 --------
-There are cases where a you may want a view to be composed of more than just a layout and a single view. The view may contain one or more sub-views, commonly referred to as partials. Scorched makes provisions for this by ignoring the default layout when ``render`` is called within a view, hence negating the requirement to explicitly override the layout.
+There are cases where a you may want a view to be composed of more than just a layout and a single view. The view may contain one or more sub-views, commonly referred to as partials. Scorched makes provisions for this by ignoring the default layout when `render` is called within a view, hence negating the requirement to explicitly override the layout.