Permalink
Browse files

regenerate contrib docs

  • Loading branch information...
1 parent 64378f9 commit 9e0dacebd9f3db87724023a5b236137ee3cdfa40 @rkh rkh committed Mar 29, 2012
@@ -1,106 +1,95 @@
+
<h1>Sinatra::ConfigFile</h1>
-<p>
-<tt>Sinatra::ConfigFile</tt> is an extension that allows you to load the
-application&#8217;s configuration from YAML files. It automatically
-detects if the files contains specific environment settings and it will use
-the corresponding to the current one.
-</p>
-<p>
-Within the application you can access those options through
-<tt>settings</tt>. If you try to get the value for a setting that
-hasn&#8217;t been defined in the config file for the current environment,
-you will get whatever it was set to in the application.
-</p>
+
+<p><tt>Sinatra::ConfigFile</tt> is an extension that allows you to load the
+application's configuration from YAML files. It automatically detects if
+the files contains specific environment settings and it will use the
+corresponding to the current one.</p>
+
+<p>Within the application you can access those options through
+<tt>settings</tt>. If you try to get the value for a setting that hasn't
+been defined in the config file for the current environment, you will get
+whatever it was set to in the application.</p>
+
<h2>Usage</h2>
-<p>
-Once you have written your configurations to a YAML file you can tell the
+
+<p>Once you have written your configurations to a YAML file you can tell the
extension to load them. See below for more information about how these
-files are interpreted.
-</p>
-<p>
-For the examples, lets assume the following config.yml file:
-</p>
-<pre>
- greeting: Welcome to my file configurable application
-</pre>
+files are interpreted.</p>
+
+<p>For the examples, lets assume the following config.yml file:</p>
+
+<pre>greeting: Welcome to my file configurable application</pre>
+
<h3>Classic Application</h3>
-<pre>
- require &quot;sinatra&quot;
- require &quot;sinatra/config_file&quot;
- config_file 'path/to/config.yml'
+<pre>require &quot;sinatra&quot;
+require &quot;sinatra/config_file&quot;
+
+config_file 'path/to/config.yml'
- get '/' do
- @greeting = settings.greeting
- haml :index
- end
+get '/' do
+ @greeting = settings.greeting
+ haml :index
+end
+
+# The rest of your classic application code goes here...</pre>
- # The rest of your classic application code goes here...
-</pre>
<h3>Modular Application</h3>
-<pre>
- require &quot;sinatra/base&quot;
- require &quot;sinatra/config_file&quot;
- class MyApp &lt; Sinatra::Base
- register Sinatra::ConfigFile
+<pre>require &quot;sinatra/base&quot;
+require &quot;sinatra/config_file&quot;
+
+class MyApp &lt; Sinatra::Base
+ register Sinatra::ConfigFile
- config_file 'path/to/config.yml'
+ config_file 'path/to/config.yml'
- get '/' do
- @greeting = settings.greeting
- haml :index
- end
+ get '/' do
+ @greeting = settings.greeting
+ haml :index
+ end
+
+ # The rest of your modular application code goes here...
+end</pre>
- # The rest of your modular application code goes here...
- end
-</pre>
<h3>Config File Format</h3>
-<p>
-In its most simple form this file is just a key-value list:
-</p>
-<pre>
- foo: bar
- something: 42
- nested:
- a: 1
- b: 2
-</pre>
-<p>
-But it also can provide specific environment configuration. There are two
+
+<p>In its most simple form this file is just a key-value list:</p>
+
+<pre>foo: bar
+something: 42
+nested:
+ a: 1
+ b: 2</pre>
+
+<p>But it also can provide specific environment configuration. There are two
ways to do that: at the file level and at the setting level. They are
-illustrated, repsectively, as follows:
-</p>
-<pre>
- development:
- foo: development
- bar: bar
- test:
- foo: test
- bar: bar
- production:
- foo: production
- bar: bar
-</pre>
-<p>
-and
-</p>
-<pre>
- foo:
- development: development
- test: test
- production: production
- bar: bar
-</pre>
-<p>
-In either case, <tt>settings.foo</tt> will return the environment name, and
-<tt>settings.bar</tt> will return <tt>&quot;bar&quot;</tt>.
-</p>
-<p>
-Be aware that if you have a different environment, besides development,
+illustrated, repsectively, as follows:</p>
+
+<pre>development:
+ foo: development
+ bar: bar
+test:
+ foo: test
+ bar: bar
+production:
+ foo: production
+ bar: bar</pre>
+
+<p>and</p>
+
+<pre>foo:
+ development: development
+ test: test
+ production: production
+bar: bar</pre>
+
+<p>In either case, <tt>settings.foo</tt> will return the environment name, and
+<tt>settings.bar</tt> will return <tt>&quot;bar&quot;</tt>.</p>
+
+<p>Be aware that if you have a different environment, besides development,
test and production, you will also need to adjust the <tt>environments</tt>
-setting. For instance, when you also have a staging environment:
-</p>
-<pre>
- set :environments, %w{development test production staging}
-</pre>
+setting. For instance, when you also have a staging environment:</p>
+
+<pre>set :environments, %w{development test production staging}</pre>
@@ -1,63 +1,57 @@
+
<h1>Sinatra::ContentFor</h1>
-<p>
-<tt>Sinatra::ContentFor</tt> is a set of helpers that allows you to capture
+
+<p><tt>Sinatra::ContentFor</tt> is a set of helpers that allows you to capture
blocks inside views to be rendered later during the request. The most
-common use is to populate different parts of your layout from your view.
-</p>
-<p>
-The currently supported engines are: Erb, Erubis, Haml and Slim.
-</p>
+common use is to populate different parts of your layout from your view.</p>
+
+<p>The currently supported engines are: Erb, Erubis, Haml and Slim.</p>
+
<h2>Usage</h2>
-<p>
-You call <tt>content_for</tt>, generally from a view, to capture a block of
-markup giving it an identifier:
-</p>
-<pre>
- # index.erb
- &lt;% content_for :some_key do %&gt;
- &lt;chunk of=&quot;html&quot;&gt;...&lt;/chunk&gt;
- &lt;% end %&gt;
-</pre>
-<p>
-Then, you call <tt>yield_content</tt> with that identifier, generally from
-a layout, to render the captured block:
-</p>
-<pre>
- # layout.erb
- &lt;%= yield_content :some_key %&gt;
-</pre>
+
+<p>You call <tt>content_for</tt>, generally from a view, to capture a block of
+markup giving it an identifier:</p>
+
+<pre># index.erb
+&lt;% content_for :some_key do %&gt;
+ &lt;chunk of=&quot;html&quot;&gt;...&lt;/chunk&gt;
+&lt;% end %&gt;</pre>
+
+<p>Then, you call <tt>yield_content</tt> with that identifier, generally from
+a layout, to render the captured block:</p>
+
+<pre># layout.erb
+&lt;%= yield_content :some_key %&gt;</pre>
+
<h3>Classic Application</h3>
-<p>
-To use the helpers in a classic application all you need to do is require
-them:
-</p>
-<pre>
- require &quot;sinatra&quot;
- require &quot;sinatra/content_for&quot;
-
- # Your classic application code goes here...
-</pre>
+
+<p>To use the helpers in a classic application all you need to do is require
+them:</p>
+
+<pre>require &quot;sinatra&quot;
+require &quot;sinatra/content_for&quot;
+
+# Your classic application code goes here...</pre>
+
<h3>Modular Application</h3>
-<p>
-To use the helpers in a modular application you need to require them, and
-then, tell the application you will use them:
-</p>
-<pre>
- require &quot;sinatra/base&quot;
- require &quot;sinatra/content_for&quot;
-
- class MyApp &lt; Sinatra::Base
- helpers Sinatra::ContentFor
-
- # The rest of your modular application code goes here...
- end
-</pre>
+
+<p>To use the helpers in a modular application you need to require them, and
+then, tell the application you will use them:</p>
+
+<pre>require &quot;sinatra/base&quot;
+require &quot;sinatra/content_for&quot;
+
+class MyApp &lt; Sinatra::Base
+ helpers Sinatra::ContentFor
+
+ # The rest of your modular application code goes here...
+end</pre>
+
<h2>And How Is This Useful?</h2>
-<p>
-For example, some of your views might need a few javascript tags and
-stylesheets, but you don&#8217;t want to force this files in all your
-pages. Then you can put <tt>&lt;% yield_content :scripts_and_styles
-%&gt;</tt> on your layout, inside the <head> tag, and each view can call
+
+<p>For example, some of your views might need a few javascript tags and
+stylesheets, but you don't want to force this files in all your pages. Then
+you can put <tt>&lt;% yield_content :scripts_and_styles %&gt;</tt> on your
+layout, inside the &lt;head&gt; tag, and each view can call
<tt>content_for</tt> setting the appropriate set of tags that should be
-added to the layout.
-</p>
+added to the layout.</p>
Oops, something went wrong.

0 comments on commit 9e0dace

Please sign in to comment.