Removed stuff about overriding validate_on_create on the AR Validations and Callbacks Guide, added new section to the Authors page

1 files changed, 9 insertions, 21 deletions

diff --git a/railties/doc/guides/html/activerecord_validations_callbacks.html b/railties/doc/guides/html/activerecord_validations_callbacks.html
index 34d911b9e2..b1f0f52736 100644
--- a/railties/doc/guides/html/activerecord_validations_callbacks.html
+++ b/railties/doc/guides/html/activerecord_validations_callbacks.html
@@ -205,7 +205,7 @@ ul#navMain {
 					<a href="#_how_it_works">How it works</a>
 						<ul>
 						
-							<li><a href="#_when_does_validation_happens">When does validation happens?</a></li>
+							<li><a href="#_when_does_validation_happen">When does validation happen?</a></li>
 						
 							<li><a href="#_the_meaning_of_em_valid_em">The meaning of <em>valid</em></a></li>
 						
@@ -391,7 +391,7 @@ Using validation directly into your Active Record classes ensures that only vali
 </div>

 <h2 id="_how_it_works">2. How it works</h2>

 <div class="sectionbody">

-<h3 id="_when_does_validation_happens">2.1. When does validation happens?</h3>

+<h3 id="_when_does_validation_happen">2.1. When does validation happen?</h3>

 <div class="paragraph"><p>There are two kinds of Active Record objects: those that correspond to a row inside your database and those who do not. When you create a fresh object, using the <tt>new</tt> method, that object does not belong to the database yet. Once you call <tt>save</tt> upon that object it&#8217;ll be recorded to it&#8217;s table. Active Record uses the <tt>new_record?</tt> instance method to discover if an object is already in the database or not. Consider the following simple and very creative Active Record class:</p></div>

 <div class="listingblock">

 <div class="content"><!-- Generator: GNU source-highlight 2.9

@@ -428,7 +428,7 @@ http://www.gnu.org/software/src-highlite -->
 <div class="sectionbody">

 <div class="paragraph"><p>Active Record offers many pre-defined validation helpers that you can use directly inside your class definitions. These helpers create validations rules that are commonly used in most of the applications that you&#8217;ll write, so you don&#8217;t need to recreate it everytime, avoiding code duplication, keeping everything organized and boosting your productivity. Everytime a validation fails, an error message is added to the object&#8217;s <tt>errors</tt> collection, this message being associated with the field being validated.</p></div>

 <div class="paragraph"><p>Each helper accepts an arbitrary number of attributes, received as symbols, so with a single line of code you can add the same kind of validation to several attributes.</p></div>

-<div class="paragraph"><p>All these helpers accept the <tt>:on</tt> and <tt>:message</tt> options, which define when the validation should be applied and what message should be added to the <tt>errors</tt> collection when it fails, respectively. The <tt>:on</tt> option takes one the values <tt>:save</tt> (it&#8217;s the default), <tt>:create</tt>  or <tt>:update</tt>. There is a default error message for each one of the validation helpers. These messages are used when the <tt>:message</tt> option isn&#8217;t used. Let&#8217;s take a look at each one of the available helpers, listed in alphabetic order.</p></div>

+<div class="paragraph"><p>All these helpers accept the <tt>:on</tt> and <tt>:message</tt> options, which define when the validation should be applied and what message should be added to the <tt>errors</tt> collection when it fails, respectively. The <tt>:on</tt> option takes one of the values <tt>:save</tt> (it&#8217;s the default), <tt>:create</tt>  or <tt>:update</tt>. There is a default error message for each one of the validation helpers. These messages are used when the <tt>:message</tt> option isn&#8217;t used. Let&#8217;s take a look at each one of the available helpers, listed in alphabetic order.</p></div>

 <h3 id="_the_tt_validates_acceptance_of_tt_helper">3.1. The <tt>validates_acceptance_of</tt> helper</h3>

 <div class="paragraph"><p>Validates that a checkbox has been checked for agreement purposes. It&#8217;s normally used when the user needs to agree with your application&#8217;s terms of service, confirm reading some clauses or any similar concept. This validation is very specific to web applications and actually this <em>acceptance</em> does not need to be recorded anywhere in your database (if you don&#8217;t have a field for it, the helper will just create a virtual attribute).</p></div>

 <div class="listingblock">

@@ -757,19 +757,7 @@ http://www.gnu.org/software/src-highlite -->
 </div>

 <h2 id="_writing_your_own_validation_methods">6. Writing your own validation methods</h2>

 <div class="sectionbody">

-<div class="paragraph"><p>When the built-in validation helpers are not enough for your needs, you can write your own validation methods, by implementing one or more of the <tt>validate</tt>, <tt>validate_on_create</tt> or <tt>validate_on_update</tt> methods. As the names of the methods states, the right method to implement depends on when you want the validations to be ran. The meaning of valid is still the same: to make an object invalid you just need to add a message to it&#8217;s <tt>errors</tt> collection.</p></div>

-<div class="listingblock">

-<div class="content"><!-- Generator: GNU source-highlight 2.9

-by Lorenzo Bettini

-http://www.lorenzobettini.it

-http://www.gnu.org/software/src-highlite -->

-<pre><tt><span style="font-weight: bold"><span style="color: #0000FF">class</span></span> Invoice <span style="color: #990000">&lt;</span> ActiveRecord<span style="color: #990000">::</span>Base

-  <span style="font-weight: bold"><span style="color: #0000FF">def</span></span> validate_on_create

-    errors<span style="color: #990000">.</span>add<span style="color: #990000">(:</span>expiration_date<span style="color: #990000">,</span> <span style="color: #FF0000">"can't be in the past"</span><span style="color: #990000">)</span> <span style="font-weight: bold"><span style="color: #0000FF">if</span></span>

-      <span style="color: #990000">!</span>expiration_date<span style="color: #990000">.</span>blank? <span style="font-weight: bold"><span style="color: #0000FF">and</span></span> expiration_date <span style="color: #990000">&lt;</span> Date<span style="color: #990000">.</span>today

-  <span style="font-weight: bold"><span style="color: #0000FF">end</span></span>

-<span style="font-weight: bold"><span style="color: #0000FF">end</span></span></tt></pre></div></div>

-<div class="paragraph"><p>If your validation rules are too complicated and you want to break them in small methods, you can implement all of them and call one of <tt>validate</tt>, <tt>validate_on_create</tt> or <tt>validate_on_update</tt> methods, passing it the symbols for the methods' names.</p></div>

+<div class="paragraph"><p>When the built-in validation helpers are not enough for your needs, you can write your own validation methods. You can do that by implementing methods that verify the state of your models and add messages to their <tt>errors</tt> collection when they are invalid. You must then register those methods by using one or more of the <tt>validate</tt>, <tt>validate_on_create</tt> or <tt>validate_on_update</tt> class methods, passing in the symbols for the validation methods' names. You can pass more than one symbol for each class method and the respective validations will be ran in the same order as they were registered.</p></div>

 <div class="listingblock">

 <div class="content"><!-- Generator: GNU source-highlight 2.9

 by Lorenzo Bettini

@@ -1284,10 +1272,10 @@ http://www.gnu.org/software/src-highlite -->
 </div>

 <h2 id="_observers">13. Observers</h2>

 <div class="sectionbody">

-<div class="paragraph"><p>Active Record callbacks are a powerful feature, but they can pollute your model implementation with code that&#8217;s not directly related to the model&#8217;s purpose. In object-oriented software, it&#8217;s always a good idea to design your classes with a single responsability in the whole system. For example, it wouldn&#8217;t make much sense to have a <tt>User</tt> model with a method that writes data about a login attempt to a log file. Whenever you&#8217;re using callbacks to write code that&#8217;s not directly related to your model class purposes, it may be a good moment to create an Observer.</p></div>

-<div class="paragraph"><p>An Active Record Observer is an object that links itself to a model and register it&#8217;s methods for callbacks. Your model&#8217;s implementation remain clean, while you can reuse the code in the Observer to add behaviuor to more than one model class. Ok, you may say that we can also do that using callback classes, but it would still force us to add code to our model&#8217;s implementation.</p></div>

-<div class="paragraph"><p>Observer classes are subclasses of the <tt>ActiveRecord::Observer</tt> class. When this class is subclassed, Active Record will look at the name of the new class and then strip the <em>Observer</em> part to find the name of the Active Record class to observe.</p></div>

-<div class="paragraph"><p>Consider a <tt>Registration</tt> model, where we want to send an email everytime a new registration is created. Since sending emails is not directly related to our model&#8217;s purpose, we could create an Observer to do just that:</p></div>

+<div class="paragraph"><p>Active Record callbacks are a powerful feature, but they can pollute your model implementation with code that&#8217;s not directly related to the model&#8217;s purpose. In object-oriented software, it&#8217;s always a good idea to design your classes with a single responsibility in the whole system. For example, it wouldn&#8217;t make much sense to have a <tt>User</tt> model with a method that writes data about a login attempt to a log file. Whenever you&#8217;re using callbacks to write code that&#8217;s not directly related to your model class purposes, it may be a good moment to create an Observer.</p></div>

+<div class="paragraph"><p>An Active Record Observer is an object that links itself to a model and registers its methods for callbacks. Your model&#8217;s implementation remains clean, while you can reuse the code in the Observer to add behaviour to more than one model class. OK, you may say that we can also do that using callback classes, but it would still force us to add code to our model&#8217;s implementation.</p></div>

+<div class="paragraph"><p>Observer classes are subclasses of the ActiveRecord::Observer class. When this class is subclassed, Active Record will look at the name of the new class and then strip the <em>Observer</em> part to find the name of the Active Record class to observe.</p></div>

+<div class="paragraph"><p>Consider a Registration model, where we want to send an email every time a new registration is created. Since sending emails is not directly related to our model&#8217;s purpose, we could create an Observer to do just that:</p></div>

 <div class="listingblock">

 <div class="content"><!-- Generator: GNU source-highlight 2.9

 by Lorenzo Bettini

@@ -1309,7 +1297,7 @@ http://www.gnu.org/software/src-highlite -->
   observe User<span style="color: #990000">,</span> Registration<span style="color: #990000">,</span> Invoice

 <span style="font-weight: bold"><span style="color: #0000FF">end</span></span></tt></pre></div></div>

 <h3 id="_registering_observers">13.1. Registering observers</h3>

-<div class="paragraph"><p>If you payed attention, you may be wondering where Active Record Observers are referenced in our applications, so they get instantiate and begin to interact with our models. For observers to work we need to register them somewhere. The usual place to do that is in our application&#8217;s <strong>config/environment.rb</strong> file. In this file there is a commented out line where we can define the observers that our application should load at start-up.</p></div>

+<div class="paragraph"><p>If you paid attention, you may be wondering where Active Record Observers are referenced in our applications, so they get instantiated and begin to interact with our models. For observers to work we need to register them somewhere. The usual place to do that is in our application&#8217;s <strong>config/environment.rb</strong> file. In this file there is a commented-out line where we can define the observers that our application should load at start-up.</p></div>

 <div class="listingblock">

 <div class="content"><!-- Generator: GNU source-highlight 2.9

 by Lorenzo Bettini