From 4a659e149a73804bd1b1795c84820eceb6870e72 Mon Sep 17 00:00:00 2001 From: burningTyger Date: Sun, 20 Feb 2011 01:19:24 +0100 Subject: [PATCH] fixed some typos et al in the README Signed-off-by: Konstantin Haase --- README.rdoc | 87 ++++++++++++++++++++++++++--------------------------- 1 file changed, 43 insertions(+), 44 deletions(-) diff --git a/README.rdoc b/README.rdoc index 33a4161084..20d0a0e1c1 100644 --- a/README.rdoc +++ b/README.rdoc @@ -571,7 +571,7 @@ Renders the embedded template string. === Accessing Variables in Templates 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 @foo = Foo.find(params[:id]) @@ -643,7 +643,7 @@ To associate a file extension with a template engine, use 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: @@ -662,9 +662,9 @@ learn more about Tilt. == Filters -Before filters are evaluated before each request within the same context as -the routes will be and can modify the request and response. Instance variables -set in filters are accessible by routes and templates: ++before+ filters are evaluated before each request within the same +context as the routes. They can modify the request and the response. Instance +variables set in these filters are accessible by routes and templates: before do @note = 'Hi!' @@ -676,9 +676,9 @@ set in filters are accessible by routes and templates: params[:splat] #=> 'bar/baz' end -After filter are evaluated after each request within the same context 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 +and can also modify the request and the response. Instance variables set in ++before+ filters and routes are accessible by +after+ filters: after do 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 generated later on. -Filters optionally taking a pattern, causing them to be evaluated only if the -request path matches that pattern: +Filters optionally taking a pattern will cause them to be evaluated only if +the request path matches the pattern: before '/protected/*' do authenticate! @@ -699,7 +699,7 @@ request path matches that pattern: session[:last_slug] = slug end -Like routes, filters also take conditions: +Like routes, filters may also take conditions: before :agent => /Songbird/ do # ... @@ -777,8 +777,8 @@ of calling another route. Simply use +call+ to achieve this: 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 method 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. @@ -789,7 +789,7 @@ Check out the Rack specification if you want to learn more about call. 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 -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 access the body: @@ -801,11 +801,10 @@ access the body: puts body end -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 -"Return Values"). +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 "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 status 418 @@ -874,7 +873,7 @@ For sending files, you can use the send_file helper method: send_file 'foo.png' end -It also take a couple of options: +It also takes a couple of options: send_file 'foo.png', :type => :jpg @@ -920,7 +919,7 @@ error handlers) through the request method: request.get? # true (similar methods for other verbs) request.form_data? # false 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.cookies # hash of browser cookies request.xhr? # is this an ajax request? @@ -968,7 +967,7 @@ able to use more than one view directory: 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' @@ -1057,20 +1056,20 @@ You can access those options via settings: settings.add_charsets << "application/foobar" [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). Only used for built-in server. [default_encoding] encoding to assume if unknown - (defaults to "utf-8") + (defaults to "utf-8"). -[dump_errors] display errors in the log +[dump_errors] display errors in the log. [environment] current environment, defaults to ENV['RACK_ENV'], - or "development" if not available + or "development" if not available. -[logging] use the logger +[logging] use the logger. [lock] Places a lock around every request, only running processing on request per Ruby process concurrently. @@ -1079,7 +1078,7 @@ You can access those options via settings: Disabled per default. [method_override] use _method 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. @@ -1088,17 +1087,17 @@ You can access those options via settings: redirect '/foo' would behave like redirect to('/foo'). 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. - enabled in development mode and on Ruby 1.8.6 (to - compensate a bug in Ruby causing a memory leak) + Enabled in development mode and on Ruby 1.8.6 (to + 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. [running] is the built-in server running now? @@ -1108,20 +1107,20 @@ You can access those options via settings: defaults to ['thin', 'mongrel', 'webrick'], order indicates 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. Disable when using a Server able to do this on its own. Disabling will boost performance. Enabled per default. -[views] views folder +[views] views folder. == 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 haml, erb, halt, etc. @@ -1160,7 +1159,7 @@ You get this: 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 '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 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 use more, switch to modular style. @@ -1325,7 +1324,7 @@ differences in the setting: === 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 run!: # my_app.rb @@ -1334,7 +1333,7 @@ There are two common options for starting a modular app, activly starting with class MyApp < Sinatra::Base # ... 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 end @@ -1530,13 +1529,13 @@ To get some of the latest features. === With Bundler 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 -Then, in you project directory, create a +Gemfile+: +Then, in your project directory, create a +Gemfile+: source :rubygems gem 'sinatra', :git => "git://github.com/sinatra/sinatra.git"