Skip to content

Commit

Permalink
fix long lines for README
Browse files Browse the repository at this point in the history 
There are still people who prefer to work in terminals with lines no
longer than 80 chars. [ci skip]
  • Loading branch information
@burningTyger
burningTyger committed Sep 13, 2014
1 parent 2192323 commit d927b7c
Showing 1 changed file with 70 additions and 70 deletions.
140 changes: 70 additions & 70 deletions README.md
View file
Expand Up @@ -480,8 +480,9 @@ Available Options:

<dt>layout</dt>
<dd>
Whether to use a layout (<tt>true</tt> or <tt>false</tt>). If it's a Symbol, specifies
what template to use. Example: <tt>erb :index, :layout => !request.xhr?</tt>
Whether to use a layout (<tt>true</tt> or <tt>false</tt>). If it's a
Symbol, specifies what template to use. Example:
<tt>erb :index, :layout => !request.xhr?</tt>
</dd>

<dt>content_type</dt>
Expand Down Expand Up @@ -821,8 +822,8 @@ template than for the layout by passing the `:layout_engine` option.
</tr>
</table>

Since you cannot call Ruby methods directly from an AsciiDoc template, you almost
always want to pass locals to it.
Since you cannot call Ruby methods directly from an AsciiDoc template, you
almost always want to pass locals to it.

#### Radius Templates

Expand Down Expand Up @@ -949,8 +950,9 @@ template than for the layout by passing the `:layout_engine` option.
</tr>
</table>

It is not possible to call methods from MediaWiki markup, nor to pass locals to it.
You therefore will usually use it in combination with another rendering engine:
It is not possible to call methods from MediaWiki markup, nor to pass locals to
it. You therefore will usually use it in combination with another rendering
engine:

``` ruby
erb :overview, :locals => { :text => mediawiki(:introduction) }
Expand Down Expand Up @@ -1086,8 +1088,8 @@ present(resource);
</tr>
</table>

Since calling ruby methods is not idiomatic in WLang, you almost always want to pass locals
to it. Layouts written in WLang and `yield` are supported, though.
Since calling ruby methods is not idiomatic in WLang, you almost always want to
pass locals to it. Layouts written in WLang and `yield` are supported, though.

### Accessing Variables in Templates

Expand Down Expand Up @@ -1127,8 +1129,7 @@ end

This code is mostly equivalent to `erb :index, :layout => :post`.

Passing blocks to rendering methods is most useful for creating nested
layouts:
Passing blocks to rendering methods is most useful for creating nested layouts:

``` ruby
erb :main_layout, :layout => false do
Expand All @@ -1147,8 +1148,7 @@ end
```

Currently, the following rendering methods accept a block: `erb`, `haml`,
`liquid`, `slim `, `wlang`.
Also the general `render` method accepts a block.
`liquid`, `slim `, `wlang`. Also the general `render` method accepts a block.

### Inline Templates

Expand Down Expand Up @@ -1268,9 +1268,9 @@ get '/foo/*' do
end
```

After filters are evaluated after each request within the same
context as the routes will be and can also modify the request and response. Instance
variables set in before filters and routes are accessible by after filters:
After filters are evaluated after each request within the same context as the
routes will be and can also modify the request and response. Instance variables
set in before filters and routes are accessible by after filters:

``` ruby
after do
Expand Down Expand Up @@ -1471,8 +1471,7 @@ end
```

Note that in the example above, you would ease testing and increase performance
by simply moving `"bar"` into a helper used by both `/foo`
and `/bar`.
by simply moving `"bar"` into a helper used by both `/foo` and `/bar`.

If you want the request to be sent to the same application instance rather than
a duplicate, use `call!` instead of `call`.
Expand Down Expand Up @@ -1597,9 +1596,8 @@ This logger will automatically take your Rack handler's logging settings into
account. If logging is disabled, this method will return a dummy object, so
you do not have to worry about it in your routes and filters.
Note that logging is only enabled for `Sinatra::Application` by
default, so if you inherit from `Sinatra::Base`, you probably want to
enable it yourself:
Note that logging is only enabled for `Sinatra::Application` by default, so if
you inherit from `Sinatra::Base`, you probably want to enable it yourself:
``` ruby
class MyApp < Sinatra::Base
Expand Down Expand Up @@ -1730,8 +1728,8 @@ end
```

To properly use caches, you should consider using `etag` or `last_modified`.
It is recommended to call those helpers *before* doing any heavy lifting, as they
will immediately flush a response if the client already has the current
It is recommended to call those helpers *before* doing any heavy lifting, as
they will immediately flush a response if the client already has the current
version in its cache:

``` ruby
Expand Down Expand Up @@ -1793,7 +1791,8 @@ etag '', :new_resource => true, :kind => :weak

### Sending Files

To return the contents of a file as the response, you can use the `send_file` helper method:
To return the contents of a file as the response, you can use the `send_file`
helper method:

``` ruby
get '/' do
Expand All @@ -1817,12 +1816,13 @@ The options are:
<dd>Value for Last-Modified header, defaults to the file's mtime.</dd>
<dt>type</dt>
<dd>Value for Content-Type header, guessed from the file extension if missing.</dd>
<dd>Value for Content-Type header, guessed from the file extension if
missing.</dd>
<dt>disposition</dt>
<dd>
Value for Content-Disposition header, possible values: <tt>nil</tt> (default),
<tt>:attachment</tt> and <tt>:inline</tt>
Value for Content-Disposition header, possible values: <tt>nil</tt>
(default), <tt>:attachment</tt> and <tt>:inline</tt>
</dd>
<dt>length</dt>
Expand All @@ -1833,8 +1833,8 @@ The options are:
Status code to be sent. Useful when sending a static file as an error page.
If supported by the Rack handler, other means than streaming from the Ruby
process will be used. If you use this helper method, Sinatra will automatically
handle range requests.
process will be used. If you use this helper method, Sinatra will
automatically handle range requests.
</dd>
</dl>
Expand Down Expand Up @@ -1876,8 +1876,7 @@ get '/foo' do
end
```
Some options, like `script_name` or `path_info`, can also be
written:
Some options, like `script_name` or `path_info`, can also be written:
``` ruby
before { request.path_info = "/" }
Expand Down Expand Up @@ -1920,9 +1919,8 @@ end
### Dealing with Date and Time
Sinatra offers a `time_for` helper method that generates a Time object
from the given value. It is also able to convert `DateTime`, `Date` and
similar classes:
Sinatra offers a `time_for` helper method that generates a Time objectfrom the
given value. It is also able to convert `DateTime`, `Date` and similar classes:
``` ruby
get '/' do
Expand Down Expand Up @@ -2116,7 +2114,9 @@ set :protection, :session => true
</dd>
<dt>bind</dt>
<dd>IP address to bind to (default: <tt>0.0.0.0</tt> <em>or</em> <tt>localhost</tt> if your `environment` is set to development.). Only used for built-in server.</dd>
<dd>IP address to bind to (default: <tt>0.0.0.0</tt> <em>or</em>
<tt>localhost</tt> if your `environment` is set to development). Only used
for built-in server.</dd>
<dt>default_encoding</dt>
<dd>Encoding to assume if unknown (defaults to <tt>"utf-8"</tt>).</dd>
Expand All @@ -2126,8 +2126,8 @@ set :protection, :session => true
<dt>environment</dt>
<dd>
Current environment. Defaults to <tt>ENV['RACK_ENV']</tt>, or <tt>"development"</tt> if
not available.
Current environment. Defaults to <tt>ENV['RACK_ENV']</tt>, or
<tt>"development"</tt> if not available.
</dd>
<dt>logging</dt>
Expand Down Expand Up @@ -2157,7 +2157,8 @@ set :protection, :session => true
</dd>

<dt>protection</dt>
<dd>Whether or not to enable web attack protections. See protection section above.</dd>
<dd>Whether or not to enable web attack protections. See protection section
above.</dd>

<dt>public_dir</dt>
<dd>Alias for <tt>public_folder</tt>. See below.</dd>
Expand All @@ -2171,12 +2172,14 @@ set :protection, :session => true

<dt>reload_templates</dt>
<dd>
Whether or not to reload templates between requests. Enabled in development mode.
Whether or not to reload templates between requests. Enabled in development
mode.
</dd>

<dt>root</dt>
<dd>
Path to project root folder. Inferred from <tt>app_file</tt> setting if not set.
Path to project root folder. Inferred from <tt>app_file</tt> setting if not
set.
</dd>

<dt>raise_errors</dt>
Expand Down Expand Up @@ -2208,30 +2211,28 @@ set :protection, :session => true

<dt>show_exceptions</dt>
<dd>
Show a stack trace in the browser when an exception
happens. Enabled by default when <tt>environment</tt>
is set to <tt>"development"</tt>, disabled otherwise.
Show a stack trace in the browser when an exception happens. Enabled by
default when <tt>environment</tt> is set to <tt>"development"</tt>,
disabled otherwise.
</dd>
<dd>
Can also be set to <tt>:after_handler</tt> to trigger
app-specified error handling before showing a stack
trace in the browser.
Can also be set to <tt>:after_handler</tt> to trigger app-specified error
handling before showing a stack trace in the browser.
</dd>

<dt>static</dt>
<dd>Whether Sinatra should handle serving static files.</dd>
<dd>Disable when using a server able to do this on its own.</dd>
<dd>Disabling will boost performance.</dd>
<dd>
Enabled per default in classic style, disabled for
modular apps.
Enabled per default in classic style, disabled for modular apps.
</dd>

<dt>static_cache_control</dt>
<dd>
When Sinatra is serving static files, set this to add
<tt>Cache-Control</tt> headers to the responses. Uses the
<tt>cache_control</tt> helper. Disabled by default.
When Sinatra is serving static files, set this to add <tt>Cache-Control</tt>
headers to the responses. Uses the <tt>cache_control</tt> helper. Disabled
by default.
</dd>
<dd>
Use an explicit array when setting multiple values:
Expand Down Expand Up @@ -2262,13 +2263,12 @@ set :protection, :session => true

## Environments

There are three predefined `environments`: `"development"`,
`"production"` and `"test"`. Environments can be set
through the `RACK_ENV` environment variable. The default value is
`"development"`. In the `"development"` environment all templates are reloaded between
requests, and special `not_found` and `error` handlers
display stack traces in your browser.
In the `"production"` and `"test"` environments, templates are cached by default.
There are three predefined `environments`: `"development"`, `"production"` and
`"test"`. Environments can be set through the `RACK_ENV` environment variable.
The default value is `"development"`. In the `"development"` environment all
templates are reloaded between requests, and special `not_found` and `error`
handlers display stack traces in your browser. In the `"production"` and
`"test"` environments, templates are cached by default.

To run different environments, set the `RACK_ENV` environment variable:

Expand Down Expand Up @@ -2310,13 +2310,13 @@ end
The `error` handler is invoked any time an exception is raised from a route
block or a filter. But note in development it will only run if you set the
show exceptions option to `:after_handler`.
show exceptions option to `:after_handler`:
```ruby
set :show_exceptions, :after_handler
```
The exception object can be obtained from the `sinatra.error` Rack variable.
The exception object can be obtained from the `sinatra.error` Rack variable:
``` ruby
error do
Expand Down Expand Up @@ -2449,8 +2449,8 @@ class MyAppTest < Test::Unit::TestCase
end
```
Note: If you are using Sinatra in the modular style, replace `Sinatra::Application`
above with the class name of your app.
Note: If you are using Sinatra in the modular style, replace
`Sinatra::Application` above with the class name of your app.
## Sinatra::Base - Middleware, Libraries, and Modular Apps
Expand All @@ -2475,8 +2475,8 @@ class MyApp < Sinatra::Base
end
```
The methods available to `Sinatra::Base` subclasses are exactly the same as those
available via the top-level DSL. Most top-level apps can be converted to
The methods available to `Sinatra::Base` subclasses are exactly the same as
those available via the top-level DSL. Most top-level apps can be converted to
`Sinatra::Base` components with two modifications:
* Your file should require `sinatra/base` instead of `sinatra`;
Expand Down Expand Up @@ -2508,10 +2508,10 @@ end
Contrary to common belief, there is nothing wrong with the classic style. If it
suits your application, you do not have to switch to a modular application.
The main disadvantage of using the classic style rather than the modular style is that
you will only have one Sinatra application per Ruby process. If you plan to use
more than one, switch to the modular style. There is no reason you cannot mix
the modular and the classic styles.
The main disadvantage of using the classic style rather than the modular style
is that you will only have one Sinatra application per Ruby process. If you
plan to use more than one, switch to the modular style. There is no reason you
cannot mix the modular and the classic styles.
If switching from one style to the other, you should be aware of slightly
different default settings:
Expand Down Expand Up @@ -2633,9 +2633,9 @@ A `config.ru` file is recommended if:
* You want to use more than one subclass of `Sinatra::Base`.
* You want to use Sinatra only for middleware, and not as an endpoint.
**There is no need to switch to a `config.ru` simply because you
switched to the modular style, and you don't have to use the modular style for running
with a `config.ru`.**
**There is no need to switch to a `config.ru` simply because you switched to
the modular style, and you don't have to use the modular style for running with
a `config.ru`.**
### Using Sinatra as Middleware
Expand Down

0 comments on commit d927b7c

Please sign in to comment.