kotovalexarian-likes-github
/
sinatra
mirror of https://github.com/sinatra/sinatra
1
0
Fork 0
Code Releases Activity

Proof-reading Scopes section

This commit is contained in:
Konstantin Haase 2010-09-24 10:15:53 +02:00
parent 3f21c3f438
commit 6233ce4390
1 changed files with 17 additions and 15 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

32
README.rdoc
View File

@ -806,7 +806,8 @@ being {included into the main namespace}[http://github.com/sinatra/sinatra/blob/
== Scopes and Binding == Scopes and Binding
The scope you are currently in determines what methods and variables are available. The scope you are currently in determines what methods and variables are
available.
=== Application/Class Scope === Application/Class Scope
@ -829,7 +830,7 @@ Options created via `set` are methods at class level:
end end
end end
You have the application scope binding inside You have the application scope binding inside:
* Your application class body * Your application class body
* Methods defined by extensions * Methods defined by extensions
@ -838,16 +839,16 @@ You have the application scope binding inside
You can reach the scope object (the class) like this: You can reach the scope object (the class) like this:
* The object passed to configure blocks (<tt>configure { |c| ... }</tt>) * Via the object passed to configure blocks (<tt>configure { |c| ... }</tt>)
* `settings` from within request scope * `settings` from within request scope
=== Request/Instance Scope === Request/Instance Scope
For every incoming request a new instance of your application class is created For every incoming request, a new instance of your application class is
and all handler blocks run in that scope. From within this scope you can created and all handler blocks run in that scope. From within this scope you
access the `request` or `session` object and call methods like `erb` or can access the `request` and `session` object or call rendering methods like
`haml`. You can access the application scope from within the request scope via `erb` or `haml`. You can access the application scope from within the request
the `settings` helper. scope via the `settings` helper:
class MyApp << Sinatra::Base class MyApp << Sinatra::Base
# Hey, I'm in the application scope! # Hey, I'm in the application scope!
@ -864,7 +865,7 @@ the `settings` helper.
end end
end end
You have the request scope binding inside You have the request scope binding inside:
* get/head/post/put/delete blocks * get/head/post/put/delete blocks
* before/after filters * before/after filters
@ -874,15 +875,16 @@ You have the request scope binding inside
=== Delegation Scope === Delegation Scope
The delegation scope just forwards methods to the class scope. However, it The delegation scope just forwards methods to the class scope. However, it
does not behave 100% like the class scope, as you do not have the classes does not behave 100% like the class scope, as you do not have the class'
bindings: Only methods explicitly marked for delegation are available and you binding: Only methods explicitly marked for delegation are available and you
do not share variables with the class scope (read: you have a different do not share variables/state with the class scope (read: you have a different
`self`). `self`). You can explicitly add method delegations by calling
<tt>Sinatra::Delegator.delegate :method_name</tt>.
You have the delegate scope binding inside You have the delegate scope binding inside:
* The top level binding, if you did <tt>require "sinatra"</tt> * The top level binding, if you did <tt>require "sinatra"</tt>
* A object extended with the `Sinatra::Delegator` mixin * An object extended with the `Sinatra::Delegator` mixin
== Command line == Command line