diff options
-rw-r--r-- | guides/source/action_mailer_basics.textile | 9 | ||||
-rw-r--r-- | guides/source/active_record_querying.textile | 2 | ||||
-rw-r--r-- | guides/source/caching_with_rails.textile | 2 | ||||
-rw-r--r-- | guides/source/debugging_rails_applications.textile | 21 | ||||
-rw-r--r-- | guides/source/form_helpers.textile | 2 |
5 files changed, 14 insertions, 22 deletions
diff --git a/guides/source/action_mailer_basics.textile b/guides/source/action_mailer_basics.textile index 9c4ce47945..5f09b8e410 100644 --- a/guides/source/action_mailer_basics.textile +++ b/guides/source/action_mailer_basics.textile @@ -412,18 +412,15 @@ The above will send a multipart email with an attachment, properly nested with t h5. Sending Emails with Dynamic Delivery Options -At times you may wish to override the default delivery options (e.g. smtp credentials) while delivering emails. This can be achieved using +delivey_method_options+ in the mailer action. +If you wish to override the default delivery options (e.g. SMTP credentials) while delivering emails, you can do this using +delivery_method_options+ in the mailer action. <ruby> class UserMailer < ActionMailer::Base def welcome_email(user,company) @user = user @url = user_url(@user) - mail(:to => user.email, - :subject => "Please see the Terms and Conditions attached", - :delivery_method_options => {:user_name => company.smtp_user, - :password => company.smtp_password, - :address => company.smtp_host}) + delivery_options = { user_name: company.smtp_user, password: company.smtp_password, address: company.smtp_host } + mail(to: user.email, subject: "Please see the Terms and Conditions attached", delivery_method_options: delivery_options) end end </ruby> diff --git a/guides/source/active_record_querying.textile b/guides/source/active_record_querying.textile index a02ef21b00..96ae5b2972 100644 --- a/guides/source/active_record_querying.textile +++ b/guides/source/active_record_querying.textile @@ -1183,7 +1183,7 @@ Client.unscoped.all This method removes all scoping and will do a normal query on the table. -Note that chaining +unscoped+ with a +scope+ does not work. In this cases, it is +Note that chaining +unscoped+ with a +scope+ does not work. In these cases, it is recommended that you use the block form of +unscoped+: <ruby> diff --git a/guides/source/caching_with_rails.textile b/guides/source/caching_with_rails.textile index 577596ac0d..712440da32 100644 --- a/guides/source/caching_with_rails.textile +++ b/guides/source/caching_with_rails.textile @@ -455,7 +455,7 @@ class ProductsController < ApplicationController end </ruby> -Instead of a options hash, you can also simply pass in a model, Rails will use the methods +updated_at+ and +cache_key+ for setting +last_modified+ and +etag+: +Instead of a options hash, you can also simply pass in a model, Rails will use the +updated_at+ and +cache_key+ methods for setting +last_modified+ and +etag+: <ruby> class ProductsController < ApplicationController diff --git a/guides/source/debugging_rails_applications.textile b/guides/source/debugging_rails_applications.textile index 99430e1e5f..a5a22a8a8f 100644 --- a/guides/source/debugging_rails_applications.textile +++ b/guides/source/debugging_rails_applications.textile @@ -189,24 +189,19 @@ Redirected to #<Post:0x20af760> Completed in 0.01224 (81 reqs/sec) | DB: 0.00044 (3%) | 302 Found [http://localhost/posts] </shell> +Adding extra logging like this makes it easy to search for unexpected or unusual behavior in your logs. If you add extra logging, be sure to make sensible use of log levels, to avoid filling your production logs with useless trivia. + h4. Tagged Logging -When running a multi-user, multi-account application, it’s a great help to be able to filter the log by who did what. TaggedLogging in Active Support helps in doing exactly that by stamping log lines with subdomains, request ids, and anything else to aid debugging such applications. +When running multi-user, multi-account applications, it’s often useful to be able to filter the logs using some custom rules. +TaggedLogging+ in Active Support helps in doing exactly that by stamping log lines with subdomains, request ids, and anything else to aid debugging such applications. + <ruby> -logger.tagged("custom_tag") { logger.info "Date is #{Time.now.to_date}" } -logger.tagged("custom_tag", "gaurish") { logger.info "multiple tags are supported" } +logger = ActiveSupport::TaggedLogging.new(Logger.new(STDOUT)) +logger.tagged("BCX") { logger.info "Stuff" } # Logs "[BCX] Stuff" +logger.tagged("BCX", "Jason") { logger.info "Stuff" } # Logs "[BCX] [Jason] Stuff" +logger.tagged("BCX") { logger.tagged("Jason") { logger.info "Stuff" } } # Logs "[BCX] [Jason] Stuff" </ruby> -Now, you filter logs by searching for +custom_tag+ & logs with tag +custom_tag+ would be returned. Here's an example using <tt>grep</tt> command -<shell> - $ grep custom_tag log/development.log -[custom_tag] Date is 2012-09-03 -[custom_tag] [gaurish] multiple tags are supported -</shell> -Tagged Logging makes it easier to filter logs & exact selected lines only. For more details and examples, check the API documentation, see "<tt>TaggedLogging</tt>":http://api.rubyonrails.org/classes/ActiveSupport/TaggedLogging.html - -Adding extra logging like this makes it easy to search for unexpected or unusual behavior in your logs. If you add extra logging, be sure to make sensible use of log levels, to avoid filling your production logs with useless trivia. - h3. Debugging with the +debugger+ gem When your code is behaving in unexpected ways, you can try printing to logs or the console to diagnose the problem. Unfortunately, there are times when this sort of error tracking is not effective in finding the root cause of a problem. When you actually need to journey into your running source code, the debugger is your best companion. diff --git a/guides/source/form_helpers.textile b/guides/source/form_helpers.textile index 4415c4d74f..d704b78f83 100644 --- a/guides/source/form_helpers.textile +++ b/guides/source/form_helpers.textile @@ -82,7 +82,7 @@ h4. Multiple Hashes in Form Helper Calls The +form_tag+ helper accepts 2 arguments: the path for the action and an options hash. This hash specifies the method of form submission and HTML options such as the form element's class. -As with the +link_to+ helper, the path argument doesn't have to be given as a string; it can be a hash of URL parameters recognizable by Rails' routing mechanism, which will turn the hash into a valid URL. However, since both arguments to +form_tag+ are hashes, you can easily run into a problem if you would like to specify both. For instance, let's say you write this: +As with the +link_to+ helper, the path argument doesn't have to be a string; it can be a hash of URL parameters recognizable by Rails' routing mechanism, which will turn the hash into a valid URL. However, since both arguments to +form_tag+ are hashes, you can easily run into a problem if you would like to specify both. For instance, let's say you write this: <ruby> form_tag(:controller => "people", :action => "search", :method => "get", :class => "nifty_form") |