README.md in ventable-0.0.3 vs README.md in ventable-0.0.4

@@ -22,12 +22,12 @@
 
 ## Usage
 
 1. Create your own plain ruby Event class that optionally carries some data important to the event. Include module ```Ventable::Event```.
 2. Create one or more observers.  Observer can be any class that implements event handler method as a class method, such as a
-   generic method ```self.handle_event(event)``` or a more specific method mapped to the event name: say for event UserRegistered the
-   callback event would be ```self.handle_user_registered_event(event)```
+   generic method ```self.handle(event)``` or a more specific method mapped to the event name: say for event UserRegistered the
+   callback event would be ```self.handle_user_registered(event)```
 3. Register your observers with the event using ```notifies``` event method, or register groups using ```group``` method, and then
    use ```notify``` with options ```inside: :group_name```
 4. Instantiate your event class (optionally with some data), and call ```fire!``` method.
 
 ## Example
@@ -46,11 +46,11 @@
   end
 end
 
 # This class is an observer, interested in WakeUpEvents.
 class SleepingPerson
-  def self.handle_wake_up_event(event)
+  def self.handle_alarm_sound event
     self.wake_up
     puts "snoozing at #{event.wakeup_time}"
     self.snooze(5)
   end
 end
@@ -62,14 +62,14 @@
 AlarmSoundEvent.new(Date.new).fire!
 ```
 
 ## Using #configure and groups
 
-Events can be configured to call observers in groups, with an optional block around it.
+Events can be configured to call observers in groups, with an optional block around it.  Using groups
+allows you (as in this example) wrap some observers in a transaction, and control the order of notification.
 
 ```ruby
-
 transaction = ->(b){
   ActiveRecord::Base.transaction do
     b.call
   end
 }
@@ -88,11 +88,10 @@
   # this block will be run as the first member of the group
   notifies inside: :transaction do
     # perform block
   end
 
-
   # this observer gets notified after all observers inside :transactions are notified
   notifies AnotherObserverClass
 
   # these two observers are called at the end of the transaction group,
   # but before AnotherObserverClass is notified.
@@ -100,25 +99,36 @@
 end
 
 SomeEvent.new.fire!
 ```
 
+## Callback Method Name
+
+When the observer is notified, Ventable library will call a class method on your observer, with the name determined
+using the following logic:
+
+1. If your event defines ```EventClass.ventable_callback_method_name``` method, it's return value is used as a method name.
+2. If not, your event's fully qualified class name is converted to a method name with underscrores. This method name
+   always begings with ```handle_```.  For example, a class ```User::RegistrationEvent``` will generate callback
+   method name ```ObserverClass.handle_user__registration(event)``` (note that '::' is converted to two underscores).
+3. If neither method is found in the observer, a generic ```ObserverClass.handle(event)``` method is called.
+
 ## Guidelines for Using Ventable with Rails
 
 You should start by defining your event library for your application (list of events
 that are important to you),  you can place these files anywhere you like, such as
 ```lib/events``` or ```app/events```, etc.
 
-It is recommended to configure all events and observers in the ```event_initializer.rb``` file,
-inside the ```config/ininitalizers``` folder.
+It is recommended to ```configure``` all events and their observers in the ```event_initializer.rb``` file,
+inside the ```config/ininitalizers``` folder.  You may need to require your events in that file also.
 
 When your event is tied to a creation of a "first class objects", such as user registration,
 it is recommended to create the User record first, commit it to the database, and then throw
-a ```ruby UserRegisteredEvent.new(user).fire!```, and have all subsequent logic broeken into
-their respective classes.  For example, if you need to send email to the user, have a ```Mailer```
-class observe the ```UserRegisteredEvent```, and so all the mailing logic can live in the ```Mailer```
-class, instead of, say, registration controller.  The callback method will receive the event, that
-wraps the User instance, or any other useful data necessary.
+a ```UserRegisteredEvent.new(user).fire!```, and have all subsequent logic broeken into
+their respective classes.  For example, if you need to send an email to the user, have a ```Mailer```
+class observe the ```UserRegisteredEvent```, and so all the mailing logic can live inside the ```Mailer```
+class, instead of, say, registration controller directly calling ```Mailer.deliver_user_registration!(user)```.
+The callback method will receive the event, that wraps the User instance, or any other useful data necessary.
 
 ## Further Discussion
 
 It is worth mentioning that in the current form this gem is simply a software design pattern.  It helps
 decouple code that performs tasks related to the same event (such as user registration, or comment posting),