diff options
Diffstat (limited to 'railties/doc/guides/source')
| -rw-r--r-- | railties/doc/guides/source/active_record_basics.txt | 29 | ||||
| -rw-r--r-- | railties/doc/guides/source/activerecord_validations_callbacks.txt | 28 | ||||
| -rw-r--r-- | railties/doc/guides/source/authors.txt | 6 |
3 files changed, 15 insertions, 48 deletions
diff --git a/railties/doc/guides/source/active_record_basics.txt b/railties/doc/guides/source/active_record_basics.txt index 892adb2d43..367a1bba5e 100644 --- a/railties/doc/guides/source/active_record_basics.txt +++ b/railties/doc/guides/source/active_record_basics.txt @@ -151,31 +151,4 @@ Rails has a reputation of being a zero-config framework which means that it aim == ActiveRecord handling the CRUD of your Rails application - Understanding the life-cycle of an ActiveRecord == Validations & Callbacks -- Validations - * create! - * validates_acceptance_of - * validates_associated - * validates_confirmation_of - * validates_each - * validates_exclusion_of - * validates_format_of - * validates_inclusion_of - * validates_length_of - * validates_numericality_of - * validates_presence_of - * validates_size_of - * validates_uniqueness_of - - Callback - * (-) save - * (-) valid - * (1) before_validation - * (2) before_validation_on_create - * (-) validate - * (-) validate_on_create - * (3) after_validation - * (4) after_validation_on_create - * (5) before_save - * (6) before_create - * (-) create - * (7) after_create - * (8) after_save +see the Validations & Callbacks guide for more info.
\ No newline at end of file diff --git a/railties/doc/guides/source/activerecord_validations_callbacks.txt b/railties/doc/guides/source/activerecord_validations_callbacks.txt index 94a8b215b5..ff2acdf8d5 100644 --- a/railties/doc/guides/source/activerecord_validations_callbacks.txt +++ b/railties/doc/guides/source/activerecord_validations_callbacks.txt @@ -24,7 +24,7 @@ There are several ways to validate the data that goes to the database, like usin == How it works -=== When does validation happens? +=== When does validation happen? 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 +new+ method, that object does not belong to the database yet. Once you call +save+ upon that object it'll be recorded to it's table. Active Record uses the +new_record?+ instance method to discover if an object is already in the database or not. Consider the following simple and very creative Active Record class: @@ -61,7 +61,7 @@ Active Record offers many pre-defined validation helpers that you can use direct 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. -All these helpers accept the +:on+ and +:message+ options, which define when the validation should be applied and what message should be added to the +errors+ collection when it fails, respectively. The +:on+ option takes one the values +:save+ (it's the default), +:create+ or +:update+. There is a default error message for each one of the validation helpers. These messages are used when the +:message+ option isn't used. Let's take a look at each one of the available helpers, listed in alphabetic order. +All these helpers accept the +:on+ and +:message+ options, which define when the validation should be applied and what message should be added to the +errors+ collection when it fails, respectively. The +:on+ option takes one of the values +:save+ (it's the default), +:create+ or +:update+. There is a default error message for each one of the validation helpers. These messages are used when the +:message+ option isn't used. Let's take a look at each one of the available helpers, listed in alphabetic order. === The +validates_acceptance_of+ helper @@ -383,19 +383,7 @@ end == Writing your own validation methods -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 +validate+, +validate_on_create+ or +validate_on_update+ 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's +errors+ collection. - -[source, ruby] ------------------------------------------------------------------- -class Invoice < ActiveRecord::Base - def validate_on_create - errors.add(:expiration_date, "can't be in the past") if - !expiration_date.blank? and expiration_date < Date.today - end -end ------------------------------------------------------------------- - -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 +validate+, +validate_on_create+ or +validate_on_update+ methods, passing it the symbols for the methods' names. +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 +errors+ collection when they are invalid. You must then register those methods by using one or more of the +validate+, +validate_on_create+ or +validate_on_update+ 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. [source, ruby] ------------------------------------------------------------------ @@ -772,13 +760,13 @@ You can declare as many callbacks as you want inside your callback classes. == Observers -Active Record callbacks are a powerful feature, but they can pollute your model implementation with code that's not directly related to the model's purpose. In object-oriented software, it's always a good idea to design your classes with a single responsability in the whole system. For example, it wouldn't make much sense to have a +User+ model with a method that writes data about a login attempt to a log file. Whenever you're using callbacks to write code that's not directly related to your model class purposes, it may be a good moment to create an Observer. +Active Record callbacks are a powerful feature, but they can pollute your model implementation with code that's not directly related to the model's purpose. In object-oriented software, it's always a good idea to design your classes with a single responsibility in the whole system. For example, it wouldn't make much sense to have a +User+ model with a method that writes data about a login attempt to a log file. Whenever you're using callbacks to write code that's not directly related to your model class purposes, it may be a good moment to create an Observer. -An Active Record Observer is an object that links itself to a model and register it's methods for callbacks. Your model'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's implementation. +An Active Record Observer is an object that links itself to a model and registers its methods for callbacks. Your model'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's implementation. -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 'Observer' part to find the name of the Active Record class to observe. +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 'Observer' part to find the name of the Active Record class to observe. -Consider a +Registration+ model, where we want to send an email everytime a new registration is created. Since sending emails is not directly related to our model's purpose, we could create an Observer to do just that: +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's purpose, we could create an Observer to do just that: [source, ruby] ------------------------------------------------------------------ @@ -802,7 +790,7 @@ end === Registering observers -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's *config/environment.rb* file. In this file there is a commented out line where we can define the observers that our application should load at start-up. +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's *config/environment.rb* file. In this file there is a commented-out line where we can define the observers that our application should load at start-up. [source, ruby] ------------------------------------------------------------------ diff --git a/railties/doc/guides/source/authors.txt b/railties/doc/guides/source/authors.txt index 987238eb4c..aaa428fd79 100644 --- a/railties/doc/guides/source/authors.txt +++ b/railties/doc/guides/source/authors.txt @@ -43,3 +43,9 @@ and unobtrusive JavaScript. His home on the internet is his blog http://tore.dar *********************************************************** Jeff Dean is a software engineer with http://pivotallabs.com/[Pivotal Labs]. *********************************************************** + +.Cássio Marques +[[cmarques]] +*********************************************************** +Cássio Marques is a Brazilian software developer working with different programming languages such as Ruby, JavaScript, C++ and Java, as an independent consultant. He blogs at http://cassiomarques.wordpress.com, which is mainly written in portuguese, but will soon get a new section for posts with english translation. +*********************************************************** |