kotovalexarian-likes-github/sinatra
1
0
Fork 0
mirror of https://github.com/sinatra/sinatra synced 2023-03-27 23:18:01 -04:00
Code Releases Activity

fixed some typos et al in the README

Browse source 
Signed-off-by: Konstantin Haase <konstantin.mailinglists@googlemail.com>
This commit is contained in:
burningTyger 2011-02-20 01:19:24 +01:00 committed by Konstantin Haase
parent 5e8815a590
commit 4a659e149a
1 changed files with 43 additions and 44 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

87
README.rdoc
View file

@ -571,7 +571,7 @@ Renders the embedded template string.
=== Accessing Variables in Templates === Accessing Variables in Templates
Templates are evaluated within the same context as route handlers. Instance Templates are evaluated within the same context as route handlers. Instance
variables set in route handlers are direcly accessible by templates: variables set in route handlers are directly accessible by templates:
get '/:id' do get '/:id' do
@foo = Foo.find(params[:id]) @foo = Foo.find(params[:id])
@ -643,7 +643,7 @@ To associate a file extension with a template engine, use
Tilt.register :tt, Tilt[:textile] Tilt.register :tt, Tilt[:textile]
=== Adding You Own Template Engine === Adding Your Own Template Engine
First, register your engine with Tilt, then create a rendering method: First, register your engine with Tilt, then create a rendering method:
@ -662,9 +662,9 @@ learn more about Tilt.
== Filters == Filters
Before filters are evaluated before each request within the same context as +before+ filters are evaluated before each request within the same
the routes will be and can modify the request and response. Instance variables context as the routes. They can modify the request and the response. Instance
set in filters are accessible by routes and templates: variables set in these filters are accessible by routes and templates:
before do before do
@note = 'Hi!' @note = 'Hi!'
@ -676,9 +676,9 @@ set in filters are accessible by routes and templates:
params[:splat] #=> 'bar/baz' params[:splat] #=> 'bar/baz'
end end
After filter are evaluated after each request within the same context and can +after+ filters are evaluated after each request within the same context
also modify the request and response. Instance variables set in before filters and can also modify the request and the response. Instance variables set in
and routes are accessible by after filters: +before+ filters and routes are accessible by +after+ filters:
after do after do
puts response.status puts response.status
@ -688,8 +688,8 @@ Note: Unless you use the +body+ method rather than just returning a String from
the routes, the body will not yet be available in the after filter, since it is the routes, the body will not yet be available in the after filter, since it is
generated later on. generated later on.
Filters optionally taking a pattern, causing them to be evaluated only if the Filters optionally taking a pattern will cause them to be evaluated only if
request path matches that pattern: the request path matches the pattern:
before '/protected/*' do before '/protected/*' do
authenticate! authenticate!
@ -699,7 +699,7 @@ request path matches that pattern:
session[:last_slug] = slug session[:last_slug] = slug
end end
Like routes, filters also take conditions: Like routes, filters may also take conditions:
before :agent => /Songbird/ do before :agent => /Songbird/ do
# ... # ...
@ -777,8 +777,8 @@ of calling another route. Simply use +call+ to achieve this:
end end
Note that in the example above, you would ease testing and increase performance Note that in the example above, you would ease testing and increase performance
by simply moving <tt>"bar"</tt> into a helper used by both <tt>/foo</tt> and by simply moving <tt>"bar"</tt> into a helper method used by both <tt>/foo</tt>
<tt>/bar</tt>. and <tt>/bar</tt>.
If you want the request to be sent to the same application instance rather than If you want the request to be sent to the same application instance rather than
a duplicate, use <tt>call!</tt> instead of <tt>call</tt>. a duplicate, use <tt>call!</tt> instead of <tt>call</tt>.
@ -789,7 +789,7 @@ Check out the Rack specification if you want to learn more about <tt>call</tt>.
It is possible and recommended to set the status code and response body with the It is possible and recommended to set the status code and response body with the
return value of the route block. However, in some scenarios you might want to return value of the route block. However, in some scenarios you might want to
set the body at an arbritary point in the execution flow. You can do so with the set the body at an arbitrary point in the execution flow. You can do so with the
+body+ helper method. If you do so, you can use that method from there on to +body+ helper method. If you do so, you can use that method from there on to
access the body: access the body:
@ -801,11 +801,10 @@ access the body:
puts body puts body
end end
It is also possible to pass a block to body, that will be executed by the rack It is also possible to pass a block to +body+, that will be executed by the Rack
handler (this can be used to implement streaming, see handler (this can be used to implement streaming, see "Return Values").
"Return Values").
Similar to the body, you can also set the status code: Similar to +body+, you can also set the status code:
get '/foo' do get '/foo' do
status 418 status 418
@ -874,7 +873,7 @@ For sending files, you can use the <tt>send_file</tt> helper method:
send_file 'foo.png' send_file 'foo.png'
end end
It also take a couple of options: It also takes a couple of options:
send_file 'foo.png', :type => :jpg send_file 'foo.png', :type => :jpg
@ -920,7 +919,7 @@ error handlers) through the <tt>request</tt> method:
request.get? # true (similar methods for other verbs) request.get? # true (similar methods for other verbs)
request.form_data? # false request.form_data? # false
request["SOME_HEADER"] # value of SOME_HEADER header request["SOME_HEADER"] # value of SOME_HEADER header
request.referer # the referer of the client or '/' request.referer # the referrer of the client or '/'
request.user_agent # user agent (used by :agent condition) request.user_agent # user agent (used by :agent condition)
request.cookies # hash of browser cookies request.cookies # hash of browser cookies
request.xhr? # is this an ajax request? request.xhr? # is this an ajax request?
@ -968,7 +967,7 @@ able to use more than one view directory:
end end
end end
Another example would be using different directories for different engines: Another example would be to use different directories for different engines:
set :views, :sass => 'views/sass', :haml => 'templates', :default => 'views' set :views, :sass => 'views/sass', :haml => 'templates', :default => 'views'
@ -1057,20 +1056,20 @@ You can access those options via <tt>settings</tt>:
settings.add_charsets << "application/foobar" settings.add_charsets << "application/foobar"
[app_file] main application file, used to detect project root, [app_file] main application file, used to detect project root,
views and public folder and inline templates views and public folder and inline templates.
[bind] IP address to bind to (default: 0.0.0.0). [bind] IP address to bind to (default: 0.0.0.0).
Only used for built-in server. Only used for built-in server.
[default_encoding] encoding to assume if unknown [default_encoding] encoding to assume if unknown
(defaults to <tt>"utf-8"</tt>) (defaults to <tt>"utf-8"</tt>).
[dump_errors] display errors in the log [dump_errors] display errors in the log.
[environment] current environment, defaults to <tt>ENV['RACK_ENV']</tt>, [environment] current environment, defaults to <tt>ENV['RACK_ENV']</tt>,
or <tt>"development"</tt> if not available or <tt>"development"</tt> if not available.
[logging] use the logger [logging] use the logger.
[lock] Places a lock around every request, only running [lock] Places a lock around every request, only running
processing on request per Ruby process concurrently. processing on request per Ruby process concurrently.
@ -1079,7 +1078,7 @@ You can access those options via <tt>settings</tt>:
Disabled per default. Disabled per default.
[method_override] use <tt>_method</tt> magic to allow put/delete forms in [method_override] use <tt>_method</tt> magic to allow put/delete forms in
browsers that don't support it browsers that don't support it.
[port] Port to listen on. Only used for built-in server. [port] Port to listen on. Only used for built-in server.
@ -1088,17 +1087,17 @@ You can access those options via <tt>settings</tt>:
<tt>redirect '/foo'</tt> would behave like <tt>redirect '/foo'</tt> would behave like
<tt>redirect to('/foo')</tt>. Disabled per default. <tt>redirect to('/foo')</tt>. Disabled per default.
[public] folder public files are server from [public] folder public files are served from
[reload_templates] whether or not to reload templates between requests. [reload_templates] whether or not to reload templates between requests.
enabled in development mode and on Ruby 1.8.6 (to Enabled in development mode and on Ruby 1.8.6 (to
compensate a bug in Ruby causing a memory leak) compensate a bug in Ruby causing a memory leak).
[root] project root folder [root] project root folder.
[raise_errors] raise exceptions (will stop application) [raise_errors] raise exceptions (will stop application).
[run] if enabled, Sinatra will handle starting the webserver, [run] if enabled, Sinatra will handle starting the web server,
do not enable if using rackup or other means. do not enable if using rackup or other means.
[running] is the built-in server running now? [running] is the built-in server running now?
@ -1108,20 +1107,20 @@ You can access those options via <tt>settings</tt>:
defaults to ['thin', 'mongrel', 'webrick'], order indicates defaults to ['thin', 'mongrel', 'webrick'], order indicates
priority. priority.
[sessions] enable cookie based sessions [sessions] enable cookie based sessions.
[show_exceptions] show a stacktrace in the browser [show_exceptions] show a stack trace in the browser.
[static] Whether Sinatra should handle serving static files. [static] Whether Sinatra should handle serving static files.
Disable when using a Server able to do this on its own. Disable when using a Server able to do this on its own.
Disabling will boost performance. Disabling will boost performance.
Enabled per default. Enabled per default.
[views] views folder [views] views folder.
== Error Handling == Error Handling
Error handlers run within the same context as routes and before filters, which Error handlers run within the same context as routes and +before+ filters, which
means you get all the goodies it has to offer, like <tt>haml</tt>, means you get all the goodies it has to offer, like <tt>haml</tt>,
<tt>erb</tt>, <tt>halt</tt>, etc. <tt>erb</tt>, <tt>halt</tt>, etc.
@ -1160,7 +1159,7 @@ You get this:
So what happened was... something bad So what happened was... something bad
Alternatively, you can install error handler for a status code: Alternatively, you can install an error handler for a status code:
error 403 do error 403 do
'Access forbidden' 'Access forbidden'
@ -1301,7 +1300,7 @@ for details on available options and their behavior.
Contrary to common believes, there is nothing wrong with classic style. If it Contrary to common believes, there is nothing wrong with classic style. If it
suits your application, you do not have to switch to a modular application. suits your application, you do not have to switch to a modular application.
There are only two downsides compared to modulare style: There are only two downsides compared to modular style:
* You may only have one Sinatra application per Ruby process - if you plan to * You may only have one Sinatra application per Ruby process - if you plan to
use more, switch to modular style. use more, switch to modular style.
@ -1325,7 +1324,7 @@ differences in the setting:
=== Serving a Modular Application === Serving a Modular Application
There are two common options for starting a modular app, activly starting with There are two common options for starting a modular app, actively starting with
<tt>run!</tt>: <tt>run!</tt>:
# my_app.rb # my_app.rb
@ -1334,7 +1333,7 @@ There are two common options for starting a modular app, activly starting with
class MyApp < Sinatra::Base class MyApp < Sinatra::Base
# ... app code here ... # ... app code here ...
# start the server if ruby file executed directly # start the server if ruby file is executed directly
run! if app_file == $0 run! if app_file == $0
end end
@ -1530,13 +1529,13 @@ To get some of the latest features.
=== With Bundler === With Bundler
If you want to run your application with the latest Sinatra, using If you want to run your application with the latest Sinatra, using
{Bundler}[http://gembundler.com/] is the recommend way. {Bundler}[http://gembundler.com/] is the recommended way.
First, install bundler, if you haven't: First, install bundler, if you haven't yet:
gem install bundler gem install bundler
Then, in you project directory, create a +Gemfile+: Then, in your project directory, create a +Gemfile+:
source :rubygems source :rubygems
gem 'sinatra', :git => "git://github.com/sinatra/sinatra.git" gem 'sinatra', :git => "git://github.com/sinatra/sinatra.git"