Skip to content
This repository
Browse code

Fixed docs (closes #2468)

git-svn-id: http://svn-commit.rubyonrails.org/rails/trunk@2749 5ecf4fe2-1ee6-0310-87b1-e25e094e27de
  • Loading branch information...
commit 82f1e19e4c493920e692309d15f66677ac8063e5 1 parent 0b92d38
David Heinemeier Hansson authored October 26, 2005
18  actionpack/lib/action_controller/assertions.rb
@@ -8,9 +8,9 @@ module Unit #:nodoc:
8 8
     # In addition to these specific assertions, you also have easy access to various collections that the regular test/unit assertions
9 9
     # can be used against. These collections are:
10 10
     #
11  
-    # * assigns: Instance variables assigned in the action that's available for the view.
  11
+    # * assigns: Instance variables assigned in the action that are available for the view.
12 12
     # * session: Objects being saved in the session.
13  
-    # * flash: The flash objects being currently in the session.
  13
+    # * flash: The flash objects currently in the session.
14 14
     # * cookies: Cookies being sent to the user on this request.
15 15
     # 
16 16
     # These collections can be used just like any other hash:
@@ -25,13 +25,13 @@ module Unit #:nodoc:
25 25
     #
26 26
     # On top of the collections, you have the complete url that a given action redirected to available in redirect_to_url.
27 27
     #
28  
-    # For redirects within the same controller, you can even call follow_redirect and the redirect will be follow triggering another
  28
+    # For redirects within the same controller, you can even call follow_redirect and the redirect will be followed, triggering another
29 29
     # action call which can then be asserted against.
30 30
     #
31 31
     # == Manipulating the request collections
32 32
     #
33  
-    # The collections described above link to the response, so you can test if what the actions were expected to do happen. But
34  
-    # some times you also want to manipulate these collections in the request coming in. This is really only relevant for sessions
  33
+    # The collections described above link to the response, so you can test if what the actions were expected to do happened. But
  34
+    # sometimes you also want to manipulate these collections in the incoming request. This is really only relevant for sessions
35 35
     # and cookies, though. For sessions, you just do:
36 36
     #
37 37
     #   @request.session[:key] = "value"
@@ -68,7 +68,7 @@ def assert_response(type, message = nil)
68 68
       end
69 69
 
70 70
       # Assert that the redirection options passed in match those of the redirect called in the latest action. This match can be partial,
71  
-      # such at assert_redirected_to(:controller => "weblog") will also match the redirection of 
  71
+      # such that assert_redirected_to(:controller => "weblog") will also match the redirection of 
72 72
       # redirect_to(:controller => "weblog", :action => "show") and so on.
73 73
       def assert_redirected_to(options = {}, message=nil)
74 74
         clean_backtrace do
@@ -118,7 +118,7 @@ def assert_template(expected = nil, message=nil)
118 118
         end
119 119
       end
120 120
 
121  
-      # Asserts that the routing of the given path is handled correctly and that the parsed options match.
  121
+      # Asserts that the routing of the given path was handled correctly and that the parsed options match.
122 122
       def assert_recognizes(expected_options, path, extras={}, message=nil)
123 123
         clean_backtrace do 
124 124
           path = "/#{path}" unless path[0..0] == '/'
@@ -159,8 +159,8 @@ def assert_generates(expected_path, options, defaults={}, extras = {}, message=n
159 159
         end
160 160
       end
161 161
 
162  
-      # asserts that path and options match both ways, in other words, the URL generated from 
163  
-      # options is same as path, and also that the options recognized from path are same as options
  162
+      # Asserts that path and options match both ways; in other words, the URL generated from 
  163
+      # options is the same as path, and also that the options recognized from path are the same as options
164 164
       def assert_routing(path, options, defaults={}, extras={}, message=nil)
165 165
         assert_recognizes(options, path, extras, message)
166 166
         
22  actionpack/lib/action_controller/base.rb
@@ -89,7 +89,7 @@ def initialize(message=nil)
89 89
   #
90 90
   # == Parameters
91 91
   #
92  
-  # All request parameters whether they come from a GET or POST request, or from the URL, are available through the params hash.
  92
+  # All request parameters, whether they come from a GET or POST request, or from the URL, are available through the params hash.
93 93
   # So an action that was performed through /weblog/list?category=All&limit=5 will include { "category" => "All", "limit" => 5 }
94 94
   # in params.
95 95
   #
@@ -165,7 +165,7 @@ def initialize(message=nil)
165 165
   # the post again, but rather just show it one more time.
166 166
   # 
167 167
   # This sounds fairly simple, but the redirection is complicated by the quest for a phenomenon known as "pretty urls". Instead of accepting
168  
-  # the dreadful beings that is "weblog_controller?action=show&post_id=5", Action Controller goes out of its way to represent the former as
  168
+  # the dreadful being that is "weblog_controller?action=show&post_id=5", Action Controller goes out of its way to represent the former as
169 169
   # "/weblog/show/5". And this is even the simple case. As an example of a more advanced pretty url consider
170 170
   # "/library/books/ISBN/0743536703/show", which can be mapped to books_controller?action=show&type=ISBN&id=0743536703.
171 171
   # 
@@ -188,7 +188,7 @@ def initialize(message=nil)
188 188
   #
189 189
   # == Calling multiple redirects or renders
190 190
   #
191  
-  # An action should conclude by a single render or redirect. Attempting to try to do either again will result in a DoubleRenderError:
  191
+  # An action should conclude with a single render or redirect. Attempting to try to do either again will result in a DoubleRenderError:
192 192
   #
193 193
   #   def do_something
194 194
   #     redirect_to :action => "elsewhere"
@@ -241,7 +241,7 @@ class Base
241 241
     @@debug_routes = true
242 242
     cattr_accessor :debug_routes
243 243
 
244  
-    # Controls whether the application is thread-safe, so multi-threaded servers like WEBrick knows whether to apply a mutex
  244
+    # Controls whether the application is thread-safe, so multi-threaded servers like WEBrick know whether to apply a mutex
245 245
     # around the performance of each action. Action Pack and Active Record are by default thread-safe, but many applications
246 246
     # may not be. Turned off by default.
247 247
     @@allow_concurrency = false
@@ -276,7 +276,7 @@ class Base
276 276
     attr_accessor :response
277 277
     
278 278
     # Holds a hash of objects in the session. Accessed like <tt>session[:person]</tt> to get the object tied to the "person"
279  
-    # key. The session will hold any type of object as values, but the key should be a string.
  279
+    # key. The session will hold any type of object as values, but the key should be a string or symbol.
280 280
     attr_accessor :session
281 281
     
282 282
     # Holds a hash of header names and values. Accessed like <tt>headers["Cache-Control"]</tt> to get the value of the Cache-Control
@@ -306,7 +306,7 @@ def controller_name
306 306
         @controller_name ||= controller_class_name.sub(/Controller$/, '').underscore
307 307
       end
308 308
       
309  
-      # Convert the class name from something like "OneModule::TwoModule::NeatController" to "one_module/two_module/neat".
  309
+      # Converts the class name from something like "OneModule::TwoModule::NeatController" to "one_module/two_module/neat".
310 310
       def controller_path
311 311
         unless @controller_path
312 312
           components = self.name.to_s.split('::')
@@ -373,7 +373,7 @@ def process(request, response, method = :perform_action, *arguments) #:nodoc:
373 373
       #  
374 374
       # <tt>url_for</tt> is used to:
375 375
       #  
376  
-      # All keys given to url_for are forwarded to the Route module save for the following:
  376
+      # All keys given to url_for are forwarded to the Route module, save for the following:
377 377
       # * <tt>:anchor</tt> -- specifies the anchor name to be appended to the path. For example, 
378 378
       #   <tt>url_for :controller => 'posts', :action => 'show', :id => 10, :anchor => 'comments'</tt> 
379 379
       #   will produce "/posts/show/10#comments".
@@ -408,7 +408,7 @@ def process(request, response, method = :perform_action, *arguments) #:nodoc:
408 408
       # The final rule is applied while the URL is being generated and is best illustrated by an example. Let us consider the
409 409
       # route given by <tt>map.connect 'people/:last/:first/:action', :action => 'bio', :controller => 'people'</tt>.
410 410
       #
411  
-      # Suppose that the current URL is "people/hh/david/contacts". Let's consider a few different cases URLs which are generated
  411
+      # Suppose that the current URL is "people/hh/david/contacts". Let's consider a few different cases of URLs which are generated
412 412
       # from this page.
413 413
       #
414 414
       # * <tt>url_for :action => 'bio'</tt> -- During the generation of this URL, default values will be used for the first and
@@ -436,7 +436,7 @@ def process(request, response, method = :perform_action, *arguments) #:nodoc:
436 436
       #   url_for :overwrite_params => { :action => 'print' }
437 437
       #
438 438
       # This takes the current URL as is and only exchanges the action. In contrast, <tt>url_for :action => 'print'</tt>
439  
-      # would have slashed-off the path components are the changed action.
  439
+      # would have slashed-off the path components after the changed action.
440 440
       def url_for(options = {}, *parameters_for_method_reference) #:doc:
441 441
         case options
442 442
           when String then options
@@ -481,7 +481,7 @@ def controller_name
481 481
       #
482 482
       # === Rendering partials
483 483
       # 
484  
-      # Partial rendering is most commonly used together with Ajax calls that only updates one or a few elements on a page
  484
+      # Partial rendering is most commonly used together with Ajax calls that only update one or a few elements on a page
485 485
       # without reloading. Rendering of partials from the controller makes it possible to use the same partial template in
486 486
       # both the full-page rendering (by calling it from within the template) and when sub-page updates happen (from the
487 487
       # controller action responding to Ajax calls). By default, the current layout is not used.
@@ -683,7 +683,7 @@ def erase_render_results
683 683
         @performed_render = false
684 684
       end
685 685
 
686  
-      # Clears the redirected results from the headers, resetting the status to 200 and returns 
  686
+      # Clears the redirected results from the headers, resets the status to 200 and returns 
687 687
       # the URL that was used to redirect or nil if there was no redirected URL
688 688
       # Note that +redirect_to+ will change the body of the response to indicate a redirection.
689 689
       # The response body is not reset here, see +erase_render_results+
10  actionpack/lib/action_controller/caching.rb
@@ -18,7 +18,7 @@ def self.append_features(base) #:nodoc:
18 18
     end
19 19
 
20 20
     # Page caching is an approach to caching where the entire action output of is stored as a HTML file that the web server 
21  
-    # can serve without going through the Action Pack. This can be as much as 100 times faster than going the process of dynamically
  21
+    # can serve without going through the Action Pack. This can be as much as 100 times faster than going through the process of dynamically
22 22
     # generating the content. Unfortunately, this incredible speed-up is only available to stateless pages where all visitors
23 23
     # are treated the same. Content management systems -- including weblogs and wikis -- have many pages that are a great fit
24 24
     # for this approach, but account-based systems where people log in and manipulate their own data are often less likely candidates.
@@ -140,7 +140,7 @@ def caching_allowed
140 140
 
141 141
     # Action caching is similar to page caching by the fact that the entire output of the response is cached, but unlike page caching, 
142 142
     # every request still goes through the Action Pack. The key benefit of this is that filters are run before the cache is served, which
143  
-    # allows for authentication and other restrictions on whether someone are supposed to see the cache. Example:
  143
+    # allows for authentication and other restrictions on whether someone is allowed to see the cache. Example:
144 144
     #
145 145
     #   class ListsController < ApplicationController
146 146
     #     before_filter :authenticate, :except => :public
@@ -228,7 +228,7 @@ def after(controller)
228 228
     # In order to use the fragment caching, you need to designate where the caches should be stored. This is done by assigning a fragment store
229 229
     # of which there are four different kinds:
230 230
     #
231  
-    # * FileStore: Keeps the fragments on disk in the +cache_path+, which works well for all types of environments and share the fragments for
  231
+    # * FileStore: Keeps the fragments on disk in the +cache_path+, which works well for all types of environments and shares the fragments for
232 232
     #   all the web server processes running off the same application directory.
233 233
     # * MemoryStore: Keeps the fragments in memory, which is fine for WEBrick and for FCGI (if you don't care that each FCGI process holds its
234 234
     #   own fragment store). It's not suitable for CGI as the process is thrown away at the end of each request. It can potentially also take
@@ -481,14 +481,14 @@ def initialize(cache_path)
481 481
     #     end
482 482
     #   end
483 483
     #
484  
-    # The sweeper is assigned on the controllers that wish to have its job performed using the <tt>cache_sweeper</tt> class method:
  484
+    # The sweeper is assigned in the controllers that wish to have its job performed using the <tt>cache_sweeper</tt> class method:
485 485
     #
486 486
     #   class ListsController < ApplicationController
487 487
     #     caches_action :index, :show, :public, :feed
488 488
     #     cache_sweeper :list_sweeper, :only => [ :edit, :destroy, :share ]
489 489
     #   end
490 490
     #
491  
-    # In the example above, four actions are cached and three actions are responsible of expiring those caches.
  491
+    # In the example above, four actions are cached and three actions are responsible for expiring those caches.
492 492
     module Sweeping
493 493
       def self.append_features(base) #:nodoc:
494 494
         super
2  actionpack/lib/action_controller/components.rb
... ...
@@ -1,5 +1,5 @@
1 1
 module ActionController #:nodoc:
2  
-  # Components allows you to call other actions for their rendered response while execution another action. You can either delegate
  2
+  # Components allows you to call other actions for their rendered response while executing another action. You can either delegate
3 3
   # the entire response rendering or you can mix a partial response in with your other content.
4 4
   #
5 5
   #   class WeblogController < ActionController::Base
6  actionpack/lib/action_controller/cookies.rb
... ...
@@ -1,6 +1,6 @@
1 1
 module ActionController #:nodoc:
2  
-  # Cookies are read and written through ActionController#cookies. The cookies being read is what was received along with the request,
3  
-  # the cookies being written is what will be sent out will the response. Cookies are read by value (so you won't get the cookie object
  2
+  # Cookies are read and written through ActionController#cookies. The cookies being read are what were received along with the request,
  3
+  # the cookies being written are what will be sent out with the response. Cookies are read by value (so you won't get the cookie object
4 4
   # itself back -- just the value it holds). Examples for writing:
5 5
   #
6 6
   #   cookies[:user_name] = "david" # => Will set a simple session cookie
@@ -43,7 +43,7 @@ def initialize(controller)
43 43
       update(@cookies)
44 44
     end
45 45
 
46  
-    # Returns the value of the cookie by +name+ -- or nil if no such cookie exist. You set new cookies using either the cookie method
  46
+    # Returns the value of the cookie by +name+ -- or nil if no such cookie exists. You set new cookies using either the cookie method
47 47
     # or cookies[]= (for simple name/value cookies without options).
48 48
     def [](name)
49 49
       @cookies[name.to_s].value.first if @cookies[name.to_s] && @cookies[name.to_s].respond_to?(:value)
2  actionpack/lib/action_controller/dependencies.rb
@@ -27,7 +27,7 @@ def self.append_features(base)
27 27
     #   end
28 28
     #
29 29
     # Also note, that if the models follow the pattern of just 1 class per file in the form of MyClass => my_class.rb, then these
30  
-    # classes doesn't have to be required as Active Support will auto-require them.
  30
+    # classes don't have to be required as Active Support will auto-require them.
31 31
     module ClassMethods
32 32
       # Specifies a variable number of models that this controller depends on. Models are normally Active Record classes or a similar
33 33
       # backend for modelling entity classes.
6  actionpack/lib/action_controller/filters.rb
@@ -41,7 +41,7 @@ def self.append_features(base)
41 41
     #
42 42
     # Now any actions performed on the BankController will have the audit method called before. On the VaultController,
43 43
     # first the audit method is called, then the verify_credentials method. If the audit method returns false, then 
44  
-    # verify_credentials and the intended action is never called.
  44
+    # verify_credentials and the intended action are never called.
45 45
     #
46 46
     # == Filter types
47 47
     #
@@ -74,7 +74,7 @@ def self.append_features(base)
74 74
     #
75 75
     # As you can see, the block expects to be passed the controller after it has assigned the request to the internal variables.
76 76
     # This means that the block has access to both the request and response objects complete with convenience methods for params,
77  
-    # session, template, and assigns. Note: The inline method doesn't strictly has to be a block. Any object that responds to call
  77
+    # session, template, and assigns. Note: The inline method doesn't strictly have to be a block; any object that responds to call
78 78
     # and returns 1 or -1 on arity will do (such as a Proc or an Method object).
79 79
     #
80 80
     # == Filter chain ordering
@@ -143,7 +143,7 @@ def self.append_features(base)
143 143
     #       end
144 144
     #   end
145 145
     # 
146  
-    # When setting conditions on inline method (proc) filters the condition must come first and be placed in parenthesis.
  146
+    # When setting conditions on inline method (proc) filters the condition must come first and be placed in parentheses.
147 147
     #
148 148
     #   class UserPreferences < ActionController::Base
149 149
     #     before_filter(:except => :new) { # some proc ... }
2  actionpack/lib/action_controller/helpers.rb
@@ -19,7 +19,7 @@ class << self
19 19
       end
20 20
     end
21 21
 
22  
-    # The template helpers serves to relieve the templates from including the same inline code again and again. It's a
  22
+    # The template helpers serve to relieve the templates from including the same inline code again and again. It's a
23 23
     # set of standardized methods for working with forms (FormHelper), dates (DateHelper), texts (TextHelper), and 
24 24
     # Active Records (ActiveRecordHelper) that's available to all templates by default.
25 25
     #
2  actionpack/lib/action_controller/layout.rb
@@ -24,7 +24,7 @@ class << self
24 24
     # and if you ever want to change the structure of these two includes, you'll have to change all the templates.
25 25
     #
26 26
     # With layouts, you can flip it around and have the common structure know where to insert changing content. This means
27  
-    # that the header and footer is only mentioned in one place, like this:
  27
+    # that the header and footer are only mentioned in one place, like this:
28 28
     #
29 29
     #   <!-- The header part of this layout -->
30 30
     #   <%= @content_for_layout %>
2  actionpack/lib/action_controller/rescue.rb
@@ -56,7 +56,7 @@ def rescue_action_in_public(exception) #:doc:
56 56
         end
57 57
       end
58 58
 
59  
-      # Overwrite to expand the meaning of a local request in order to show local rescues on other occurences than
  59
+      # Overwrite to expand the meaning of a local request in order to show local rescues on other occurrences than
60 60
       # the remote IP being 127.0.0.1. For example, this could include the IP of the developer machine when debugging
61 61
       # remotely.
62 62
       def local_request? #:doc:

0 notes on commit 82f1e19

Please sign in to comment.
Something went wrong with that request. Please try again.