diff options
author | Pratik Naik <pratiknaik@gmail.com> | 2009-02-03 22:52:07 +0000 |
---|---|---|
committer | Pratik Naik <pratiknaik@gmail.com> | 2009-02-03 22:52:07 +0000 |
commit | a0f5e0b6d9de6594e5a83a4d8eaf7ee9ec1754c9 (patch) | |
tree | e92a7bfd6def8b7fce289476c406a8101f9a2681 /railties | |
parent | 34a37ea9e8265972a93f0c4f62e44308c27751dd (diff) | |
download | rails-a0f5e0b6d9de6594e5a83a4d8eaf7ee9ec1754c9.tar.gz rails-a0f5e0b6d9de6594e5a83a4d8eaf7ee9ec1754c9.tar.bz2 rails-a0f5e0b6d9de6594e5a83a4d8eaf7ee9ec1754c9.zip |
Merge docrails
Diffstat (limited to 'railties')
-rw-r--r-- | railties/doc/guides/html/action_mailer_basics.html | 52 | ||||
-rw-r--r-- | railties/doc/guides/html/association_basics.html | 33 | ||||
-rw-r--r-- | railties/doc/guides/html/command_line.html | 73 | ||||
-rw-r--r-- | railties/doc/guides/html/getting_started_with_rails.html | 44 | ||||
-rw-r--r-- | railties/doc/guides/html/i18n.html | 3 | ||||
-rw-r--r-- | railties/doc/guides/source/action_mailer_basics.txt | 52 | ||||
-rw-r--r-- | railties/doc/guides/source/association_basics.txt | 41 | ||||
-rw-r--r-- | railties/doc/guides/source/command_line.txt | 68 | ||||
-rw-r--r-- | railties/doc/guides/source/getting_started_with_rails.txt | 2 | ||||
-rw-r--r-- | railties/doc/guides/source/i18n.txt | 4 |
10 files changed, 281 insertions, 91 deletions
diff --git a/railties/doc/guides/html/action_mailer_basics.html b/railties/doc/guides/html/action_mailer_basics.html index 22b575af45..38f127fea8 100644 --- a/railties/doc/guides/html/action_mailer_basics.html +++ b/railties/doc/guides/html/action_mailer_basics.html @@ -37,9 +37,9 @@ <a href="#_sending_emails">Sending Emails</a> <ul> - <li><a href="#_walkthrough_to_generating_a_mailer">Walkthrough to generating a Mailer</a></li> + <li><a href="#_walkthrough_to_generating_a_mailer">Walkthrough to generating a mailer</a></li> - <li><a href="#_action_mailer_and_dynamic_deliver_methods">Action Mailer and dynamic deliver_ methods</a></li> + <li><a href="#_action_mailer_and_dynamic_deliver_methods">Action Mailer and dynamic deliver_* methods</a></li> <li><a href="#_complete_list_of_actionmailer_user_settable_attributes">Complete List of ActionMailer user-settable attributes</a></li> @@ -86,18 +86,18 @@ <h1>Action Mailer Basics</h1> <div id="preamble">
<div class="sectionbody">
-<div class="paragraph"><p>This guide should provide you with all you need to get started in sending and receiving emails from/to your application, and many internals of the ActionMailer class. It will also cover how to test your mailers.</p></div>
+<div class="paragraph"><p>This guide should provide you with all you need to get started in sending and receiving emails from/to your application, and many internals of Action Mailer. It will also cover how to test your mailers.</p></div>
</div>
</div>
<h2 id="_introduction">1. Introduction</h2>
<div class="sectionbody">
<div class="paragraph"><p>Action Mailer allows you to send email from your application using a mailer model and views.
-Yes, that is correct, in Rails, emails are used by creating models that inherit from ActionMailer::Base. They live alongside other models in /app/models BUT they have views just like controllers that appear alongside other views in app/views.</p></div>
+Yes, that is correct, in Rails, emails are used by creating models that inherit from ActionMailer::Base. They live alongside other models in <tt>app/models</tt> but they have views just like controllers that appear alongside other views in <tt>app/views</tt>.</p></div>
</div>
<h2 id="_sending_emails">2. Sending Emails</h2>
<div class="sectionbody">
<div class="paragraph"><p>Let’s say you want to send a welcome email to a user after they signup. Here is how you would go about this:</p></div>
-<h3 id="_walkthrough_to_generating_a_mailer">2.1. Walkthrough to generating a Mailer</h3>
+<h3 id="_walkthrough_to_generating_a_mailer">2.1. Walkthrough to generating a mailer</h3>
<h4 id="_create_the_mailer">2.1.1. Create the mailer:</h4>
<div class="listingblock">
<div class="content"><!-- Generator: GNU source-highlight 2.9
@@ -113,7 +113,7 @@ create app/models/user_mailer<span style="color: #990000">.</span>rb create test/unit/user_mailer_test<span style="color: #990000">.</span>rb</tt></pre></div></div>
<div class="paragraph"><p>So we got the model, the fixtures, and the tests all created for us</p></div>
<h4 id="_edit_the_model">2.1.2. Edit the model:</h4>
-<div class="paragraph"><p>If you look at app/models/user_mailer.rb, you will see:</p></div>
+<div class="paragraph"><p>If you look at <tt>app/models/user_mailer.rb</tt>, you will see:</p></div>
<div class="listingblock">
<div class="content"><!-- Generator: GNU source-highlight 2.9
by Lorenzo Bettini
@@ -122,7 +122,7 @@ http://www.gnu.org/software/src-highlite --> <pre><tt><span style="font-weight: bold"><span style="color: #0000FF">class</span></span> UserMailer <span style="color: #990000"><</span> ActionMailer<span style="color: #990000">::</span>Base
<span style="font-weight: bold"><span style="color: #0000FF">end</span></span></tt></pre></div></div>
-<div class="paragraph"><p>Lets add a method called welcome_email, that will send an email to the user’s registered email address:</p></div>
+<div class="paragraph"><p>Lets add a method called <tt>welcome_email</tt>, that will send an email to the user’s registered email address:</p></div>
<div class="listingblock">
<div class="content"><!-- Generator: GNU source-highlight 2.9
by Lorenzo Bettini
@@ -132,7 +132,7 @@ http://www.gnu.org/software/src-highlite --> <span style="font-weight: bold"><span style="color: #0000FF">def</span></span> welcome_email<span style="color: #990000">(</span>user<span style="color: #990000">)</span>
recipients user<span style="color: #990000">.</span>email
- from <span style="color: #FF0000">"My Awesome Site Notifications<notifications@example.com>"</span>
+ from <span style="color: #FF0000">"My Awesome Site Notifications <notifications@example.com>"</span>
subject <span style="color: #FF0000">"Welcome to My Awesome Site"</span>
sent_on Time<span style="color: #990000">.</span>now
body <span style="color: #FF0000">{</span><span style="color: #990000">:</span>user <span style="color: #990000">=></span> user<span style="color: #990000">,</span> <span style="color: #990000">:</span>url <span style="color: #990000">=></span> <span style="color: #FF0000">"http://example.com/login"</span><span style="color: #FF0000">}</span>
@@ -151,7 +151,7 @@ cellspacing="0" cellpadding="4"> <tbody valign="top">
<tr>
<td align="left"><p class="table">recipients</p></td>
-<td align="left"><p class="table">who the recipients are, put in an array for multiple, ie, @recipients = ["user1@example.com", "user2@example.com"]</p></td>
+<td align="left"><p class="table">The recipients of the email. It can be a string or, if there are multiple recipients, an array of strings</p></td>
</tr>
<tr>
<td align="left"><p class="table">from</p></td>
@@ -172,7 +172,7 @@ cellspacing="0" cellpadding="4"> </tbody>
</table>
</div>
-<div class="paragraph"><p>How about @body[:user]? Well anything you put in the @body hash will appear in the mailer view (more about mailer views below) as an instance variable ready for you to use, ie, in our example the mailer view will have a @user instance variable available for its consumption.</p></div>
+<div class="paragraph"><p>The keys of the hash passed to <tt>body</tt> become instance variables in the view. Thus, in our example the mailer view will have a @user and a @url instance variables available.</p></div>
<h4 id="_create_the_mailer_view">2.1.3. Create the mailer view</h4>
<div class="paragraph"><p></p></div>
<div class="paragraph"><p>The file can look like:</p></div>
@@ -184,21 +184,21 @@ http://www.gnu.org/software/src-highlite --> <pre><tt><span style="font-weight: bold"><span style="color: #000080"><!DOCTYPE</span></span> <span style="color: #009900">html</span> <span style="color: #009900">PUBLIC</span> <span style="color: #FF0000">"-//W3C//DTD XHTML 1.0 Transitional//EN"</span> <span style="color: #FF0000">"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"</span><span style="font-weight: bold"><span style="color: #000080">></span></span>
<span style="font-weight: bold"><span style="color: #0000FF"><html></span></span>
<span style="font-weight: bold"><span style="color: #0000FF"><head></span></span>
- <span style="font-weight: bold"><span style="color: #0000FF"><meta</span></span> <span style="color: #009900">content</span><span style="color: #990000">=</span><span style="color: #009900">'text/html;</span> <span style="color: #009900">charset</span><span style="color: #990000">=</span><span style="color: #009900">iso-8859-1'</span> <span style="color: #009900">http-equiv</span><span style="color: #990000">=</span><span style="color: #009900">'Content-Type'</span> <span style="font-weight: bold"><span style="color: #0000FF">/></span></span>
+ <span style="font-weight: bold"><span style="color: #0000FF"><meta</span></span> <span style="color: #009900">content</span><span style="color: #990000">=</span><span style="color: #FF0000">"text/html; charset=UTF-8"</span> <span style="color: #009900">http-equiv</span><span style="color: #990000">=</span><span style="color: #FF0000">"Content-Type"</span> <span style="font-weight: bold"><span style="color: #0000FF">/></span></span>
<span style="font-weight: bold"><span style="color: #0000FF"></head></span></span>
<span style="font-weight: bold"><span style="color: #0000FF"><body></span></span>
- <span style="font-weight: bold"><span style="color: #0000FF"><h1></span></span>Welcome to example.com, <%= @user.first_name %><span style="font-weight: bold"><span style="color: #0000FF"></h1></span></span>
+ <span style="font-weight: bold"><span style="color: #0000FF"><h1></span></span>Welcome to example.com, <%=h @user.first_name %><span style="font-weight: bold"><span style="color: #0000FF"></h1></span></span>
<span style="font-weight: bold"><span style="color: #0000FF"><p></span></span>
- You have successfully signed up to example.com, and your username is: <%= @user.login %>.<span style="font-weight: bold"><span style="color: #0000FF"><br/></span></span>
- To login to the site, just follow this link: <%= @url %>.
+ You have successfully signed up to example.com, and your username is: <%=h @user.login %>.<span style="font-weight: bold"><span style="color: #0000FF"><br/></span></span>
+ To login to the site, just follow this link: <%=h @url %>.
<span style="font-weight: bold"><span style="color: #0000FF"></p></span></span>
<span style="font-weight: bold"><span style="color: #0000FF"><p></span></span>Thanks for joining and have a great day!<span style="font-weight: bold"><span style="color: #0000FF"></p></span></span>
<span style="font-weight: bold"><span style="color: #0000FF"></body></span></span>
<span style="font-weight: bold"><span style="color: #0000FF"></html></span></span></tt></pre></div></div>
<h4 id="_wire_it_up_so_that_the_system_sends_the_email_when_a_user_signs_up">2.1.4. Wire it up so that the system sends the email when a user signs up</h4>
-<div class="paragraph"><p>There are 3 ways to achieve this. One is to send the email from the controller that sends the email, another is to put it in a before_create block in the user model, and the last one is to use an observer on the user model. Whether you use the second or third methods is up to you, but staying away from the first is recommended. Not because it’s wrong, but because it keeps your controller clean, and keeps all logic related to the user model within the user model. This way, whichever way a user is created (from a web form, or from an API call, for example), we are guaranteed that the email will be sent.</p></div>
+<div class="paragraph"><p>There are three ways to achieve this. One is to send the email from the controller that sends the email, another is to put it in a <tt>before_create</tt> callback in the user model, and the last one is to use an observer on the user model. Whether you use the second or third methods is up to you, but staying away from the first is recommended. Not because it’s wrong, but because it keeps your controller clean, and keeps all logic related to the user model within the user model. This way, whichever way a user is created (from a web form, or from an API call, for example), we are guaranteed that the email will be sent.</p></div>
<div class="paragraph"><p>Let’s see how we would go about wiring it up using an observer:</p></div>
-<div class="paragraph"><p>In config/environment.rb:</p></div>
+<div class="paragraph"><p>In <tt>config/environment.rb</tt>:</p></div>
<div class="listingblock">
<div class="content"><!-- Generator: GNU source-highlight 2.9
by Lorenzo Bettini
@@ -207,11 +207,8 @@ http://www.gnu.org/software/src-highlite --> <pre><tt><span style="font-style: italic"><span style="color: #9A1900"># Code that already exists</span></span>
Rails<span style="color: #990000">::</span>Initializer<span style="color: #990000">.</span>run <span style="font-weight: bold"><span style="color: #0000FF">do</span></span> <span style="color: #990000">|</span>config<span style="color: #990000">|</span>
-
<span style="font-style: italic"><span style="color: #9A1900"># Code that already exists</span></span>
-
config<span style="color: #990000">.</span>active_record<span style="color: #990000">.</span>observers <span style="color: #990000">=</span> <span style="color: #990000">:</span>user_observer
-
<span style="font-weight: bold"><span style="color: #0000FF">end</span></span></tt></pre></div></div>
<div class="paragraph"><p>There was a bit of a debate on where to put observers. Some people put them in app/models, but a cleaner method may be to create an app/observers folder to store all observers, and add that to your load path. Open config/environment.rb and make it look like:</p></div>
<div class="listingblock">
@@ -230,8 +227,7 @@ Rails<span style="color: #990000">::</span>Initializer<span style="color: #99000 config<span style="color: #990000">.</span>active_record<span style="color: #990000">.</span>observers <span style="color: #990000">=</span> <span style="color: #990000">:</span>user_observer
<span style="font-weight: bold"><span style="color: #0000FF">end</span></span></tt></pre></div></div>
-<div class="paragraph"><p>ALMOST THERE :) Now all we need is that danged observer, and we’re done:
-Create a file called user_observer in app/models or app/observers depending on where you stored it, and make it look like:</p></div>
+<div class="paragraph"><p>Now create a file called user_observer in app/models or app/observers depending on where you stored it, and make it look like:</p></div>
<div class="listingblock">
<div class="content"><!-- Generator: GNU source-highlight 2.9
by Lorenzo Bettini
@@ -242,17 +238,17 @@ http://www.gnu.org/software/src-highlite --> UserMailer<span style="color: #990000">.</span>deliver_welcome_email<span style="color: #990000">(</span>user<span style="color: #990000">)</span>
<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>Notice how we call deliver_welcome_email? Where is that method? Well if you remember, we created a method called welcome_email in UserMailer, right? Well, as part of the "magic" of rails, we deliver the email identified by welcome_email by calling deliver_welcome_email. The next section will go through this in more detail.</p></div>
+<div class="paragraph"><p>Notice how we call <tt>deliver_welcome_email</tt>? Where is that method? Well if you remember, we created a method called <tt>welcome_email</tt> in UserMailer, right? Well, as part of the "magic" of Rails, we deliver the email identified by <tt>welcome_email</tt> by calling <tt>deliver_welcome_email</tt>. The next section will go through this in more detail.</p></div>
<div class="paragraph"><p>That’s it! Now whenever your users signup, they will be greeted with a nice welcome email.</p></div>
-<h3 id="_action_mailer_and_dynamic_deliver_methods">2.2. Action Mailer and dynamic deliver_ methods</h3>
+<h3 id="_action_mailer_and_dynamic_deliver_methods">2.2. Action Mailer and dynamic deliver_* methods</h3>
<div class="paragraph"><p>So how does Action Mailer understand this deliver_welcome_email call? If you read the documentation (<a href="http://api.rubyonrails.org/files/vendor/rails/actionmailer/README.html">http://api.rubyonrails.org/files/vendor/rails/actionmailer/README.html</a>), you will find this in the "Sending Emails" section:</p></div>
<div class="paragraph"><p>You never instantiate your mailer class. Rather, your delivery instance
methods are automatically wrapped in class methods that start with the word
-deliver_ followed by the name of the mailer method that you would
-like to deliver. The signup_notification method defined above is
-delivered by invoking Notifier.deliver_signup_notification.</p></div>
+"deliver_" followed by the name of the mailer method that you would
+like to deliver. The <tt>welcome_email</tt> method defined above is
+delivered by invoking <tt>Notifier.deliver_welcome_email</tt>.</p></div>
<div class="paragraph"><p>So, how exactly does this work?</p></div>
-<div class="paragraph"><p>In ActionMailer:Base, you will find this:</p></div>
+<div class="paragraph"><p>In ActionMailer::Base, you will find this:</p></div>
<div class="listingblock">
<div class="content"><!-- Generator: GNU source-highlight 2.9
by Lorenzo Bettini
@@ -266,7 +262,7 @@ http://www.gnu.org/software/src-highlite --> <span style="font-weight: bold"><span style="color: #0000FF">else</span></span> <span style="font-weight: bold"><span style="color: #0000FF">super</span></span>
<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>Ah, this makes things so much clearer :) so if the method name starts with deliver_ followed by any combination of lowercase letters or underscore, method missing calls new on your mailer class (UserMailer in our example above), sending the combination of lower case letters or underscore, along with the parameter. The resulting object is then sent the deliver! method, which well... delivers it.</p></div>
+<div class="paragraph"><p>Hence, if the method name starts with "deliver_" followed by any combination of lowercase letters or underscore, <tt>method_missing+ calls `new</tt> on your mailer class (UserMailer in our example above), sending the combination of lower case letters or underscore, along with the parameters. The resulting object is then sent the <tt>deliver!</tt> method, which well... delivers it.</p></div>
<h3 id="_complete_list_of_actionmailer_user_settable_attributes">2.3. Complete List of ActionMailer user-settable attributes</h3>
<div class="tableblock">
<table rules="all"
diff --git a/railties/doc/guides/html/association_basics.html b/railties/doc/guides/html/association_basics.html index bfe8f3f341..0aaad5b5bd 100644 --- a/railties/doc/guides/html/association_basics.html +++ b/railties/doc/guides/html/association_basics.html @@ -791,6 +791,11 @@ http://www.gnu.org/software/src-highlite --> <div class="ulist"><ul>
<li>
<p>
+<tt>:autosave</tt>
+</p>
+</li>
+<li>
+<p>
<tt>:class_name</tt>
</p>
</li>
@@ -840,6 +845,8 @@ http://www.gnu.org/software/src-highlite --> </p>
</li>
</ul></div>
+<h5 id="_tt_autosave_tt"><tt>:autosave</tt></h5>
+<div class="paragraph"><p>If you set the <tt>:autosave</tt> option to <tt>true</tt>, Rails will save any loaded members and destroy members that are marked for destruction whenever you save the parent object.</p></div>
<h5 id="_tt_class_name_tt"><tt>:class_name</tt></h5>
<div class="paragraph"><p>If the name of the other model cannot be derived from the association name, you can use the <tt>:class_name</tt> option to supply the model name. For example, if an order belongs to a customer, but the actual name of the model containing customers is <tt>Patron</tt>, you’d set things up this way:</p></div>
<div class="listingblock">
@@ -1099,6 +1106,11 @@ http://www.gnu.org/software/src-highlite --> </li>
<li>
<p>
+<tt>:autosave</tt>
+</p>
+</li>
+<li>
+<p>
<tt>:class_name</tt>
</p>
</li>
@@ -1165,6 +1177,8 @@ http://www.gnu.org/software/src-highlite --> </ul></div>
<h5 id="_tt_as_tt"><tt>:as</tt></h5>
<div class="paragraph"><p>Setting the <tt>:as</tt> option indicates that this is a polymorphic association. Polymorphic associations are discussed in detail later in this guide.</p></div>
+<h5 id="_tt_autosave_tt_2"><tt>:autosave</tt></h5>
+<div class="paragraph"><p>If you set the <tt>:autosave</tt> option to <tt>true</tt>, Rails will save any loaded members and destroy members that are marked for destruction whenever you save the parent object.</p></div>
<h5 id="_tt_class_name_tt_2"><tt>:class_name</tt></h5>
<div class="paragraph"><p>If the name of the other model cannot be derived from the association name, you can use the <tt>:class_name</tt> option to supply the model name. For example, if a supplier has an account, but the actual name of the model containing accounts is Billing, you’d set things up this way:</p></div>
<div class="listingblock">
@@ -1467,6 +1481,11 @@ http://www.gnu.org/software/src-highlite --> </li>
<li>
<p>
+<tt>:autosave</tt>
+</p>
+</li>
+<li>
+<p>
<tt>:class_name</tt>
</p>
</li>
@@ -1568,6 +1587,8 @@ http://www.gnu.org/software/src-highlite --> </ul></div>
<h5 id="_tt_as_tt_2"><tt>:as</tt></h5>
<div class="paragraph"><p>Setting the <tt>:as</tt> option indicates that this is a polymorphic association, as discussed earlier in this guide.</p></div>
+<h5 id="_tt_autosave_tt_3"><tt>:autosave</tt></h5>
+<div class="paragraph"><p>If you set the <tt>:autosave</tt> option to <tt>true</tt>, Rails will save any loaded members and destroy members that are marked for destruction whenever you save the parent object.</p></div>
<h5 id="_tt_class_name_tt_3"><tt>:class_name</tt></h5>
<div class="paragraph"><p>If the name of the other model cannot be derived from the association name, you can use the <tt>:class_name</tt> option to supply the model name. For example, if a customer has many orders, but the actual name of the model containing orders is <tt>Transaction</tt>, you’d set things up this way:</p></div>
<div class="listingblock">
@@ -1953,6 +1974,11 @@ http://www.gnu.org/software/src-highlite --> </li>
<li>
<p>
+<tt>:autosave</tt>
+</p>
+</li>
+<li>
+<p>
<tt>:class_name</tt>
</p>
</li>
@@ -2061,6 +2087,8 @@ http://www.gnu.org/software/src-highlite --> has_and_belongs_to_many <span style="color: #990000">:</span>friends<span style="color: #990000">,</span> <span style="color: #990000">:</span>class_name <span style="color: #990000">=></span> <span style="color: #FF0000">"User"</span><span style="color: #990000">,</span>
<span style="color: #990000">:</span>foreign_key <span style="color: #990000">=></span> <span style="color: #FF0000">"this_user_id"</span><span style="color: #990000">,</span> <span style="color: #990000">:</span>association_foreign_key <span style="color: #990000">=></span> <span style="color: #FF0000">"other_user_id"</span>
<span style="font-weight: bold"><span style="color: #0000FF">end</span></span></tt></pre></div></div>
+<h5 id="_tt_autosave_tt_4"><tt>:autosave</tt></h5>
+<div class="paragraph"><p>If you set the <tt>:autosave</tt> option to <tt>true</tt>, Rails will save any loaded members and destroy members that are marked for destruction whenever you save the parent object.</p></div>
<h5 id="_tt_class_name_tt_4"><tt>:class_name</tt></h5>
<div class="paragraph"><p>If the name of the other model cannot be derived from the association name, you can use the <tt>:class_name</tt> option to supply the model name. For example, if a part has many assemblies, but the actual name of the model containing assemblies is <tt>Gadget</tt>, you’d set things up this way:</p></div>
<div class="listingblock">
@@ -2293,6 +2321,11 @@ http://www.gnu.org/software/src-highlite --> <div class="ulist"><ul>
<li>
<p>
+February 1, 2009: Added <tt>:autosave</tt> option <a href="../authors.html#mgunderloy">Mike Gunderloy</a>
+</p>
+</li>
+<li>
+<p>
September 28, 2008: Corrected <tt>has_many :through</tt> diagram, added polymorphic diagram, some reorganization by <a href="../authors.html#mgunderloy">Mike Gunderloy</a> . First release version.
</p>
</li>
diff --git a/railties/doc/guides/html/command_line.html b/railties/doc/guides/html/command_line.html index 226a68e105..14db786b78 100644 --- a/railties/doc/guides/html/command_line.html +++ b/railties/doc/guides/html/command_line.html @@ -54,6 +54,14 @@ </ul> </li> + <li> + <a href="#_the_rails_advanced_command_line_racl">The Rails Advanced Command Line (RACL!)</a> + <ul> + + <li><a href="#_rails_with_databases_and_scm">rails with databases and SCM</a></li> + + </ul> + </li> </ol> </div> @@ -169,7 +177,7 @@ http://www.gnu.org/software/src-highlite --> <td class="content">WEBrick isn’t your only option for serving Rails. We’ll get to that in a later section. [XXX: which section]</td>
</tr></table>
</div>
-<div class="paragraph"><p>Here we’ll flex our <tt>server</tt> command, which without any prodding of any kind will run our new shiny Rails app:</p></div>
+<div class="paragraph"><p>Without any prodding of any kind, <tt>server</tt> will run our new shiny Rails app:</p></div>
<div class="listingblock">
<div class="content"><!-- Generator: GNU source-highlight 2.9
by Lorenzo Bettini
@@ -447,7 +455,7 @@ $ <span style="color: #990000">.</span>/script/destroy model Oops notempty app/models
notempty app</tt></pre></div></div>
<h3 id="_about">1.9. about</h3>
-<div class="paragraph"><p>Check it: Version numbers for Ruby, RubyGems, Rails, the Rails subcomponents, your application’s folder, the current Rails environment name, your app’s database adapter, and schema version! <tt>about</tt> is useful when you need to ask help, check if a security patch might affect you, or when you need some stats for an existing Rails installation.</p></div>
+<div class="paragraph"><p>Check it: Version numbers for Ruby, RubyGems, Rails, the Rails subcomponents, your application’s folder, the current Rails environment name, your app’s database adapter, and schema version! <tt>about</tt> is useful when you need to ask for help, check if a security patch might affect you, or when you need some stats for an existing Rails installation.</p></div>
<div class="listingblock">
<div class="content"><!-- Generator: GNU source-highlight 2.9
by Lorenzo Bettini
@@ -469,6 +477,67 @@ About your application<span style="color: #FF0000">'s environment</span> <span style="color: #FF0000">Database adapter sqlite3</span>
<span style="color: #FF0000">Database schema version 20081217073400</span></tt></pre></div></div>
</div>
+<h2 id="_the_rails_advanced_command_line_racl">2. The Rails Advanced Command Line (RACL!)</h2>
+<div class="sectionbody">
+<div class="paragraph"><p>The more advanced uses of the command line are focused around finding useful (even surprising at times) options in the utilities, and fitting utilities to your needs and specific work flow. Listed here are some tricks up Rails' sleeve.</p></div>
+<h3 id="_rails_with_databases_and_scm">2.1. rails with databases and SCM</h3>
+<div class="paragraph"><p>When creating a new Rails application, you have the option to specify what kind of database and what kind of source code management system your application is going to use. This will save you a few minutes, and certainly many keystrokes.</p></div>
+<div class="paragraph"><p>Let’s see what a <tt>--git</tt> option and a <tt>--database=postgresql</tt> option will do for us:</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>$ mkdir gitapp
+$ cd gitapp
+$ git init
+Initialized empty Git repository <span style="font-weight: bold"><span style="color: #0000FF">in</span></span> <span style="color: #990000">.</span>git<span style="color: #990000">/</span>
+$ rails <span style="color: #990000">.</span> --git --database<span style="color: #990000">=</span>postgresql
+ exists
+ create app/controllers
+ create app/helpers
+<span style="color: #990000">...</span>
+<span style="color: #990000">...</span>
+ create tmp/cache
+ create tmp/pids
+ create Rakefile
+add <span style="color: #FF0000">'Rakefile'</span>
+ create README
+add <span style="color: #FF0000">'README'</span>
+ create app/controllers/application<span style="color: #990000">.</span>rb
+add <span style="color: #FF0000">'app/controllers/application.rb'</span>
+ create app/helpers/application_helper<span style="color: #990000">.</span>rb
+<span style="color: #990000">...</span>
+ create log/test<span style="color: #990000">.</span>log
+add <span style="color: #FF0000">'log/test.log'</span></tt></pre></div></div>
+<div class="paragraph"><p>We had to create the <strong>gitapp</strong> directory and initialize an empty git repository before Rails would add files it created to our repository. Let’s see what it put in our database configuration:</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>$ cat config/database<span style="color: #990000">.</span>yml
+<span style="font-style: italic"><span style="color: #9A1900"># PostgreSQL. Versions 7.4 and 8.x are supported.</span></span>
+<span style="font-style: italic"><span style="color: #9A1900">#</span></span>
+<span style="font-style: italic"><span style="color: #9A1900"># Install the ruby-postgres driver:</span></span>
+<span style="font-style: italic"><span style="color: #9A1900"># gem install ruby-postgres</span></span>
+<span style="font-style: italic"><span style="color: #9A1900"># On Mac OS X:</span></span>
+<span style="font-style: italic"><span style="color: #9A1900"># gem install ruby-postgres -- --include=/usr/local/pgsql</span></span>
+<span style="font-style: italic"><span style="color: #9A1900"># On Windows:</span></span>
+<span style="font-style: italic"><span style="color: #9A1900"># gem install ruby-postgres</span></span>
+<span style="font-style: italic"><span style="color: #9A1900"># Choose the win32 build.</span></span>
+<span style="font-style: italic"><span style="color: #9A1900"># Install PostgreSQL and put its /bin directory on your path.</span></span>
+development<span style="color: #990000">:</span>
+ adapter<span style="color: #990000">:</span> postgresql
+ encoding<span style="color: #990000">:</span> unicode
+ database<span style="color: #990000">:</span> gitapp_development
+ pool<span style="color: #990000">:</span> <span style="color: #993399">5</span>
+ username<span style="color: #990000">:</span> gitapp
+ password<span style="color: #990000">:</span>
+<span style="color: #990000">...</span>
+<span style="color: #990000">...</span></tt></pre></div></div>
+<div class="paragraph"><p>It also generated some lines in our database.yml configuration corresponding to our choice of PostgreSQL for database. The only catch with using the SCM options is that you have to make your application’s directory first, then initialize your SCM, then you can run the <tt>rails</tt> command to generate the basis of your app.</p></div>
+</div>
</div> </div> diff --git a/railties/doc/guides/html/getting_started_with_rails.html b/railties/doc/guides/html/getting_started_with_rails.html index 564d5c7c00..bd1ce052ac 100644 --- a/railties/doc/guides/html/getting_started_with_rails.html +++ b/railties/doc/guides/html/getting_started_with_rails.html @@ -1828,13 +1828,43 @@ Running <tt>rake doc:rails</tt> will put a full copy of the API documentation fo <h2 id="_changelog">11. Changelog</h2>
<div class="sectionbody">
<div class="paragraph"><p><a href="http://rails.lighthouseapp.com/projects/16213-rails-guides/tickets/2">Lighthouse ticket</a></p></div>
-<div class="paragraph"><p>*
-* November 3, 2008: Formatting patch from Dave Rothlisberger
-* November 1, 2008: First approved version by <a href="../authors.html#mgunderloy">Mike Gunderloy</a>
-* October 16, 2008: Revised based on feedback from Pratik Naik by <a href="../authors.html#mgunderloy">Mike Gunderloy</a> (not yet approved for publication)
-* October 13, 2008: First complete draft by <a href="../authors.html#mgunderloy">Mike Gunderloy</a> (not yet approved for publication)
-* October 12, 2008: More detail, rearrangement, editing by <a href="../authors.html#mgunderloy">Mike Gunderloy</a> (not yet approved for publication)
-* September 8, 2008: initial version by James Miller (not yet approved for publication)</p></div>
+<div class="ulist"><ul>
+<li>
+<p>
+February 1, 2009: Updated for Rails 2.3 by <a href="../authors.html#mgunderloy">Mike Gunderloy</a>
+</p>
+</li>
+<li>
+<p>
+November 3, 2008: Formatting patch from Dave Rothlisberger
+</p>
+</li>
+<li>
+<p>
+November 1, 2008: First approved version by <a href="../authors.html#mgunderloy">Mike Gunderloy</a>
+</p>
+</li>
+<li>
+<p>
+October 16, 2008: Revised based on feedback from Pratik Naik by <a href="../authors.html#mgunderloy">Mike Gunderloy</a> (not yet approved for publication)
+</p>
+</li>
+<li>
+<p>
+October 13, 2008: First complete draft by <a href="../authors.html#mgunderloy">Mike Gunderloy</a> (not yet approved for publication)
+</p>
+</li>
+<li>
+<p>
+October 12, 2008: More detail, rearrangement, editing by <a href="../authors.html#mgunderloy">Mike Gunderloy</a> (not yet approved for publication)
+</p>
+</li>
+<li>
+<p>
+September 8, 2008: initial version by James Miller (not yet approved for publication)
+</p>
+</li>
+</ul></div>
</div>
</div> diff --git a/railties/doc/guides/html/i18n.html b/railties/doc/guides/html/i18n.html index b0d52c0ff5..8deee39779 100644 --- a/railties/doc/guides/html/i18n.html +++ b/railties/doc/guides/html/i18n.html @@ -504,7 +504,7 @@ private <span style="font-weight: bold"><span style="color: #0000FF">def</span></span> extract_locale_from_accept_language_header
request<span style="color: #990000">.</span>env<span style="color: #990000">[</span><span style="color: #FF0000">'HTTP_ACCEPT_LANGUAGE'</span><span style="color: #990000">].</span>scan<span style="color: #990000">(</span><span style="color: #FF6600">/^[a-z]{2}/</span><span style="color: #990000">).</span>first
<span style="font-weight: bold"><span style="color: #0000FF">end</span></span></tt></pre></div></div>
-<div class="paragraph"><p>Of course, in production environment you would need much robust code, and could use a plugin such as Iaian Hecker’s <a href="http://github.com/iain/http_accept_language">http_accept_language</a>.</p></div>
+<div class="paragraph"><p>Of course, in production environment you would need much robust code, and could use a plugin such as Iaian Hecker’s <a href="http://github.com/iain/http_accept_language">http_accept_language</a> or even Rack middleware such as Ryan Tomayko’s <a href="http://github.com/rtomayko/rack-contrib/blob/master/lib/rack/locale.rb">locale</a>.</p></div>
<h4 id="_using_geoip_or_similar_database">2.6.2. Using GeoIP (or similar) database</h4>
<div class="paragraph"><p>Another way of choosing the locale from client’s information would be to use a database for mapping client IP to region, such as <a href="http://www.maxmind.com/app/geolitecountry">GeoIP Lite Country</a>. The mechanics of the code would be very similar to the code above — you would need to query database for user’s IP, and lookup your preffered locale for the country/region/city returned.</p></div>
<h4 id="_user_profile">2.6.3. User profile</h4>
@@ -598,6 +598,7 @@ pirate<span style="color: #990000">:</span> <td class="content">You need to restart the server when you add new locale files.</td>
</tr></table>
</div>
+<div class="paragraph"><p>You may use YAML (<tt>.yml</tt>) or plain Ruby (<tt>.rb</tt>) files for storing your translations in SimpleStore. YAML is the preffered option among Rails developers, has one big disadvantage, though. YAML is very sensitive to whitespace and special characters, so the application may not load your dictionary properly. Ruby files will crash your application on first request, so you may easily find what’s wrong. (If you encounter any "weird issues" with YAML dictionaries, try putting the relevant portion of your dictionary into Ruby file.)</p></div>
<h3 id="_adding_date_time_formats">3.2. Adding Date/Time formats</h3>
<div class="paragraph"><p>OK! Now let’s add a timestamp to the view, so we can demo the <strong>date/time localization</strong> feature as well. To localize the time format you pass the Time object to <tt>I18n.l</tt> or (preferably) use Rails' <tt>#l</tt> helper. You can pick a format by passing the <tt>:format</tt> option — by default the <tt>:default</tt> format is used.</p></div>
<div class="listingblock">
diff --git a/railties/doc/guides/source/action_mailer_basics.txt b/railties/doc/guides/source/action_mailer_basics.txt index c7700d1678..6224a7b15b 100644 --- a/railties/doc/guides/source/action_mailer_basics.txt +++ b/railties/doc/guides/source/action_mailer_basics.txt @@ -1,16 +1,16 @@ Action Mailer Basics ==================== -This guide should provide you with all you need to get started in sending and receiving emails from/to your application, and many internals of the ActionMailer class. It will also cover how to test your mailers. +This guide should provide you with all you need to get started in sending and receiving emails from/to your application, and many internals of Action Mailer. It will also cover how to test your mailers. == Introduction Action Mailer allows you to send email from your application using a mailer model and views. -Yes, that is correct, in Rails, emails are used by creating models that inherit from ActionMailer::Base. They live alongside other models in /app/models BUT they have views just like controllers that appear alongside other views in app/views. +Yes, that is correct, in Rails, emails are used by creating models that inherit from ActionMailer::Base. They live alongside other models in `app/models` but they have views just like controllers that appear alongside other views in `app/views`. == Sending Emails Let's say you want to send a welcome email to a user after they signup. Here is how you would go about this: -=== Walkthrough to generating a Mailer +=== Walkthrough to generating a mailer ==== Create the mailer: [source, shell] ------------------------------------------------------- @@ -27,7 +27,7 @@ So we got the model, the fixtures, and the tests all created for us ==== Edit the model: -If you look at app/models/user_mailer.rb, you will see: +If you look at `app/models/user_mailer.rb`, you will see: [source, ruby] ------------------------------------------------------- class UserMailer < ActionMailer::Base @@ -35,14 +35,14 @@ class UserMailer < ActionMailer::Base end ------------------------------------------------------- -Lets add a method called welcome_email, that will send an email to the user's registered email address: +Lets add a method called `welcome_email`, that will send an email to the user's registered email address: [source, ruby] ------------------------------------------------------- class UserMailer < ActionMailer::Base def welcome_email(user) recipients user.email - from "My Awesome Site Notifications<notifications@example.com>" + from "My Awesome Site Notifications <notifications@example.com>" subject "Welcome to My Awesome Site" sent_on Time.now body {:user => user, :url => "http://example.com/login"} @@ -55,17 +55,17 @@ end So what do we have here? [width="100%", cols="20%,80%"] |====================================================== -|recipients| who the recipients are, put in an array for multiple, ie, @recipients = ["user1@example.com", "user2@example.com"] +|recipients| The recipients of the email. It can be a string or, if there are multiple recipients, an array of strings |from| Who the email will appear to come from in the recipients' mailbox |subject| The subject of the email |sent_on| Timestamp for the email |content_type| The content type, by default is text/plain |====================================================== -How about @body[:user]? Well anything you put in the @body hash will appear in the mailer view (more about mailer views below) as an instance variable ready for you to use, ie, in our example the mailer view will have a @user instance variable available for its consumption. +The keys of the hash passed to `body` become instance variables in the view. Thus, in our example the mailer view will have a @user and a @url instance variables available. ==== Create the mailer view -Create a file called welcome_email.html.erb in #{RAILS_ROOT}/app/views/user_mailer/ . This will be the template used for the email. This file will be used for html formatted emails. Had we wanted to send text-only emails, the file would have been called welcome_email.txt.erb, and we would have set the content type to text/plain in the mailer model. +Create a file called `welcome_email.html.erb` in #{RAILS_ROOT}/app/views/user_mailer/ . This will be the template used for the email. This file will be used for html formatted emails. Had we wanted to send text-only emails, the file would have been called welcome_email.txt.erb, and we would have set the content type to text/plain in the mailer model. The file can look like: [source, html] @@ -73,13 +73,13 @@ The file can look like: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html> <head> - <meta content='text/html; charset=iso-8859-1' http-equiv='Content-Type' /> + <meta content="text/html; charset=UTF-8" http-equiv="Content-Type" /> </head> <body> - <h1>Welcome to example.com, <%= @user.first_name %></h1> + <h1>Welcome to example.com, <%=h @user.first_name %></h1> <p> - You have successfully signed up to example.com, and your username is: <%= @user.login %>.<br/> - To login to the site, just follow this link: <%= @url %>. + You have successfully signed up to example.com, and your username is: <%=h @user.login %>.<br/> + To login to the site, just follow this link: <%=h @url %>. </p> <p>Thanks for joining and have a great day!</p> </body> @@ -87,21 +87,18 @@ The file can look like: ------------------------------------------------------- ==== Wire it up so that the system sends the email when a user signs up -There are 3 ways to achieve this. One is to send the email from the controller that sends the email, another is to put it in a before_create block in the user model, and the last one is to use an observer on the user model. Whether you use the second or third methods is up to you, but staying away from the first is recommended. Not because it's wrong, but because it keeps your controller clean, and keeps all logic related to the user model within the user model. This way, whichever way a user is created (from a web form, or from an API call, for example), we are guaranteed that the email will be sent. +There are three ways to achieve this. One is to send the email from the controller that sends the email, another is to put it in a `before_create` callback in the user model, and the last one is to use an observer on the user model. Whether you use the second or third methods is up to you, but staying away from the first is recommended. Not because it's wrong, but because it keeps your controller clean, and keeps all logic related to the user model within the user model. This way, whichever way a user is created (from a web form, or from an API call, for example), we are guaranteed that the email will be sent. Let's see how we would go about wiring it up using an observer: -In config/environment.rb: +In `config/environment.rb`: [source, ruby] ------------------------------------------------------- # Code that already exists Rails::Initializer.run do |config| - # Code that already exists - config.active_record.observers = :user_observer - end ------------------------------------------------------- @@ -121,8 +118,7 @@ Rails::Initializer.run do |config| end ------------------------------------------------------- -ALMOST THERE :) Now all we need is that danged observer, and we're done: -Create a file called user_observer in app/models or app/observers depending on where you stored it, and make it look like: +Now create a file called user_observer in app/models or app/observers depending on where you stored it, and make it look like: [source, ruby] ------------------------------------------------------- class UserObserver < ActiveRecord::Observer @@ -132,22 +128,22 @@ class UserObserver < ActiveRecord::Observer end ------------------------------------------------------- -Notice how we call deliver_welcome_email? Where is that method? Well if you remember, we created a method called welcome_email in UserMailer, right? Well, as part of the "magic" of rails, we deliver the email identified by welcome_email by calling deliver_welcome_email. The next section will go through this in more detail. +Notice how we call `deliver_welcome_email`? Where is that method? Well if you remember, we created a method called `welcome_email` in UserMailer, right? Well, as part of the "magic" of Rails, we deliver the email identified by `welcome_email` by calling `deliver_welcome_email`. The next section will go through this in more detail. That's it! Now whenever your users signup, they will be greeted with a nice welcome email. -=== Action Mailer and dynamic deliver_ methods +=== Action Mailer and dynamic deliver_* methods So how does Action Mailer understand this deliver_welcome_email call? If you read the documentation (http://api.rubyonrails.org/files/vendor/rails/actionmailer/README.html), you will find this in the "Sending Emails" section: You never instantiate your mailer class. Rather, your delivery instance methods are automatically wrapped in class methods that start with the word -deliver_ followed by the name of the mailer method that you would -like to deliver. The signup_notification method defined above is -delivered by invoking Notifier.deliver_signup_notification. +"deliver_" followed by the name of the mailer method that you would +like to deliver. The `welcome_email` method defined above is +delivered by invoking `Notifier.deliver_welcome_email`. So, how exactly does this work? -In ActionMailer:Base, you will find this: +In ActionMailer::Base, you will find this: [source, ruby] ------------------------------------------------------- def method_missing(method_symbol, *parameters)#:nodoc: @@ -160,7 +156,7 @@ def method_missing(method_symbol, *parameters)#:nodoc: end ------------------------------------------------------- -Ah, this makes things so much clearer :) so if the method name starts with deliver_ followed by any combination of lowercase letters or underscore, method missing calls new on your mailer class (UserMailer in our example above), sending the combination of lower case letters or underscore, along with the parameter. The resulting object is then sent the deliver! method, which well... delivers it. +Hence, if the method name starts with "deliver_" followed by any combination of lowercase letters or underscore, `method_missing+ calls `new` on your mailer class (UserMailer in our example above), sending the combination of lower case letters or underscore, along with the parameters. The resulting object is then sent the `deliver!` method, which well... delivers it. === Complete List of ActionMailer user-settable attributes @@ -480,4 +476,4 @@ class UserMailerTest < ActionMailer::TestCase What have we done? Well, we sent the email and stored the returned object in the email variable. We then ensured that it was sent (the first assert), then, in the second batch of assertion, we ensure that the email does indeed contain the values that we expect. == Epilogue -This guide presented how to create a mailer and how to test it. In reality, you may find that writing your tests before you actually write your code to be a rewarding experience. It may take some time to get used to TDD (Test Driven Development), but coding this way achieves two major benefits. Firstly, you know that the code does indeed work, because the tests fail (because there's no code), then they pass, because the code that satisfies the tests was written. Secondly, when you start with the tests, you don't have to make time AFTER you write the code, to write the tests, then never get around to it. The tests are already there and testing has now become part of your coding regimen.
\ No newline at end of file +This guide presented how to create a mailer and how to test it. In reality, you may find that writing your tests before you actually write your code to be a rewarding experience. It may take some time to get used to TDD (Test Driven Development), but coding this way achieves two major benefits. Firstly, you know that the code does indeed work, because the tests fail (because there's no code), then they pass, because the code that satisfies the tests was written. Secondly, when you start with the tests, you don't have to make time AFTER you write the code, to write the tests, then never get around to it. The tests are already there and testing has now become part of your coding regimen. diff --git a/railties/doc/guides/source/association_basics.txt b/railties/doc/guides/source/association_basics.txt index 95d7397558..80605c1e83 100644 --- a/railties/doc/guides/source/association_basics.txt +++ b/railties/doc/guides/source/association_basics.txt @@ -624,7 +624,7 @@ end The +belongs_to+ association supports these options: -// * +:accessible+ +* +:autosave+ * +:class_name+ * +:conditions+ * +:counter_cache+ @@ -636,10 +636,10 @@ The +belongs_to+ association supports these options: * +:select+ * +:validate+ -// ===== +:accessible+ -// -// The +:accessible+ option is the association version of +ActiveRecord::Base#attr_accessible+. If you set the +:accessible+ option to true, then mass // assignment is allowed for this association. -// +===== +:autosave+ + +If you set the +:autosave+ option to +true+, Rails will save any loaded members and destroy members that are marked for destruction whenever you save the parent object. + ===== +:class_name+ If the name of the other model cannot be derived from the association name, you can use the +:class_name+ option to supply the model name. For example, if an order belongs to a customer, but the actual name of the model containing customers is +Patron+, you'd set things up this way: @@ -877,8 +877,8 @@ end The +has_one+ association supports these options: -// * +:accessible+ * +:as+ +* +:autosave+ * +:class_name+ * +:conditions+ * +:dependent+ @@ -893,14 +893,14 @@ The +has_one+ association supports these options: * +:through+ * +:validate+ -// ===== +:accessible+ -// -// The +:accessible+ option is the association version of +ActiveRecord::Base#attr_accessible+. If you set the +:accessible+ option to true, then mass // assignment is allowed for this association. -// ===== +:as+ Setting the +:as+ option indicates that this is a polymorphic association. Polymorphic associations are discussed in detail later in this guide. +===== +:autosave+ + +If you set the +:autosave+ option to +true+, Rails will save any loaded members and destroy members that are marked for destruction whenever you save the parent object. + ===== +:class_name+ If the name of the other model cannot be derived from the association name, you can use the +:class_name+ option to supply the model name. For example, if a supplier has an account, but the actual name of the model containing accounts is Billing, you'd set things up this way: @@ -1181,8 +1181,8 @@ end The +has_many+ association supports these options: -// * +:accessible+ * +:as+ +* +:autosave+ * +:class_name+ * +:conditions+ * +:counter_sql+ @@ -1204,14 +1204,14 @@ The +has_many+ association supports these options: * +:uniq+ * +:validate+ -// ===== +:accessible+ -// -// The +:accessible+ option is the association version of +ActiveRecord::Base#attr_accessible+. If you set the +:accessible+ option to true, then mass // assignment is allowed for this association. -// ===== +:as+ Setting the +:as+ option indicates that this is a polymorphic association, as discussed earlier in this guide. +===== +:autosave+ + +If you set the +:autosave+ option to +true+, Rails will save any loaded members and destroy members that are marked for destruction whenever you save the parent object. + ===== +:class_name+ If the name of the other model cannot be derived from the association name, you can use the +:class_name+ option to supply the model name. For example, if a customer has many orders, but the actual name of the model containing orders is +Transaction+, you'd set things up this way: @@ -1566,8 +1566,8 @@ end The +has_and_belongs_to_many+ association supports these options: -// * +:accessible+ * +:association_foreign_key+ +* +:autosave+ * +:class_name+ * +:conditions+ * +:counter_sql+ @@ -1587,10 +1587,6 @@ The +has_and_belongs_to_many+ association supports these options: * +:uniq+ * +:validate+ -// ===== +:accessible+ -// -// The +:accessible+ option is the association version of +ActiveRecord::Base#attr_accessible+. If you set the +:accessible+ option to true, then mass // assignment is allowed for this association. -// ===== +:association_foreign_key+ By convention, Rails guesses that the column in the join table used to hold the foreign key pointing to the other model is the name of that model with the suffix +_id+ added. The +:association_foreign_key+ option lets you set the name of the foreign key directly: @@ -1605,6 +1601,10 @@ class User < ActiveRecord::Base end ------------------------------------------------------- +===== +:autosave+ + +If you set the +:autosave+ option to +true+, Rails will save any loaded members and destroy members that are marked for destruction whenever you save the parent object. + ===== +:class_name+ If the name of the other model cannot be derived from the association name, you can use the +:class_name+ option to supply the model name. For example, if a part has many assemblies, but the actual name of the model containing assemblies is +Gadget+, you'd set things up this way: @@ -1841,6 +1841,7 @@ Extensions can refer to the internals of the association proxy using these three http://rails.lighthouseapp.com/projects/16213-rails-guides/tickets/11[Lighthouse ticket] +* February 1, 2009: Added +:autosave+ option link:../authors.html#mgunderloy[Mike Gunderloy] * September 28, 2008: Corrected +has_many :through+ diagram, added polymorphic diagram, some reorganization by link:../authors.html#mgunderloy[Mike Gunderloy] . First release version. * September 22, 2008: Added diagrams, misc. cleanup by link:../authors.html#mgunderloy[Mike Gunderloy] (not yet approved for publication) * September 14, 2008: initial version by link:../authors.html#mgunderloy[Mike Gunderloy] (not yet approved for publication) diff --git a/railties/doc/guides/source/command_line.txt b/railties/doc/guides/source/command_line.txt index 8a887bd001..4f1dd49f35 100644 --- a/railties/doc/guides/source/command_line.txt +++ b/railties/doc/guides/source/command_line.txt @@ -56,7 +56,7 @@ Let's try it! The `server` command launches a small web server named WEBrick whi NOTE: WEBrick isn't your only option for serving Rails. We'll get to that in a later section. [XXX: which section] -Here we'll flex our `server` command, which without any prodding of any kind will run our new shiny Rails app: +Without any prodding of any kind, `server` will run our new shiny Rails app: [source,shell] ------------------------------------------------------ @@ -318,7 +318,7 @@ $ ./script/destroy model Oops ------------------------------------------------------ === about === -Check it: Version numbers for Ruby, RubyGems, Rails, the Rails subcomponents, your application's folder, the current Rails environment name, your app's database adapter, and schema version! `about` is useful when you need to ask help, check if a security patch might affect you, or when you need some stats for an existing Rails installation. +Check it: Version numbers for Ruby, RubyGems, Rails, the Rails subcomponents, your application's folder, the current Rails environment name, your app's database adapter, and schema version! `about` is useful when you need to ask for help, check if a security patch might affect you, or when you need some stats for an existing Rails installation. [source,shell] ------------------------------------------------------ @@ -337,4 +337,66 @@ Application root /home/commandsapp Environment development Database adapter sqlite3 Database schema version 20081217073400 -------------------------------------------------------
\ No newline at end of file +------------------------------------------------------ + +== The Rails Advanced Command Line (RACL!) == +The more advanced uses of the command line are focused around finding useful (even surprising at times) options in the utilities, and fitting utilities to your needs and specific work flow. Listed here are some tricks up Rails' sleeve. + +=== rails with databases and SCM === +When creating a new Rails application, you have the option to specify what kind of database and what kind of source code management system your application is going to use. This will save you a few minutes, and certainly many keystrokes. + +Let's see what a `--git` option and a `--database=postgresql` option will do for us: + +[source,shell] +------------------------------------------------------ +$ mkdir gitapp +$ cd gitapp +$ git init +Initialized empty Git repository in .git/ +$ rails . --git --database=postgresql + exists + create app/controllers + create app/helpers +... +... + create tmp/cache + create tmp/pids + create Rakefile +add 'Rakefile' + create README +add 'README' + create app/controllers/application.rb +add 'app/controllers/application.rb' + create app/helpers/application_helper.rb +... + create log/test.log +add 'log/test.log' +------------------------------------------------------ + +We had to create the *gitapp* directory and initialize an empty git repository before Rails would add files it created to our repository. Let's see what it put in our database configuration: + +[source,shell] +------------------------------------------------------ +$ cat config/database.yml +# PostgreSQL. Versions 7.4 and 8.x are supported. +# +# Install the ruby-postgres driver: +# gem install ruby-postgres +# On Mac OS X: +# gem install ruby-postgres -- --include=/usr/local/pgsql +# On Windows: +# gem install ruby-postgres +# Choose the win32 build. +# Install PostgreSQL and put its /bin directory on your path. +development: + adapter: postgresql + encoding: unicode + database: gitapp_development + pool: 5 + username: gitapp + password: +... +... +------------------------------------------------------ + +It also generated some lines in our database.yml configuration corresponding to our choice of PostgreSQL for database. The only catch with using the SCM options is that you have to make your application's directory first, then initialize your SCM, then you can run the `rails` command to generate the basis of your app.
\ No newline at end of file diff --git a/railties/doc/guides/source/getting_started_with_rails.txt b/railties/doc/guides/source/getting_started_with_rails.txt index 43322822fe..34bd6ca5e5 100644 --- a/railties/doc/guides/source/getting_started_with_rails.txt +++ b/railties/doc/guides/source/getting_started_with_rails.txt @@ -1342,7 +1342,7 @@ Rails also comes with built-in help that you can generate using the rake command http://rails.lighthouseapp.com/projects/16213-rails-guides/tickets/2[Lighthouse ticket] -* +* February 1, 2009: Updated for Rails 2.3 by link:../authors.html#mgunderloy[Mike Gunderloy] * November 3, 2008: Formatting patch from Dave Rothlisberger * November 1, 2008: First approved version by link:../authors.html#mgunderloy[Mike Gunderloy] * October 16, 2008: Revised based on feedback from Pratik Naik by link:../authors.html#mgunderloy[Mike Gunderloy] (not yet approved for publication) diff --git a/railties/doc/guides/source/i18n.txt b/railties/doc/guides/source/i18n.txt index 4465a77289..19393f4527 100644 --- a/railties/doc/guides/source/i18n.txt +++ b/railties/doc/guides/source/i18n.txt @@ -315,7 +315,7 @@ def extract_locale_from_accept_language_header end ------------------------------------------------------- -Of course, in production environment you would need much robust code, and could use a plugin such as Iaian Hecker's http://github.com/iain/http_accept_language[http_accept_language]. +Of course, in production environment you would need much robust code, and could use a plugin such as Iaian Hecker's http://github.com/iain/http_accept_language[http_accept_language] or even Rack middleware such as Ryan Tomayko's http://github.com/rtomayko/rack-contrib/blob/master/lib/rack/locale.rb[locale]. ==== Using GeoIP (or similar) database @@ -403,6 +403,8 @@ image:images/i18n/demo_translated_pirate.png[rails i18n demo translated to pirat NOTE: You need to restart the server when you add new locale files. +You may use YAML (+.yml+) or plain Ruby (+.rb+) files for storing your translations in SimpleStore. YAML is the preffered option among Rails developers, has one big disadvantage, though. YAML is very sensitive to whitespace and special characters, so the application may not load your dictionary properly. Ruby files will crash your application on first request, so you may easily find what's wrong. (If you encounter any "weird issues" with YAML dictionaries, try putting the relevant portion of your dictionary into Ruby file.) + === Adding Date/Time formats OK! Now let's add a timestamp to the view, so we can demo the *date/time localization* feature as well. To localize the time format you pass the Time object to +I18n.l+ or (preferably) use Rails' +#l+ helper. You can pick a format by passing the +:format+ option -- by default the +:default+ format is used. |