Skip to content
Permalink
Browse files
Observers are no longer important enough to get this configuration op… 
…tion called out at the top level
  • Loading branch information
@dhh
dhh committed Aug 7, 2012
1 parent 7ef56d6 commit 775ddf2e69ab0bfaed17c691cf79999974d62dca
Showing 1 changed file with 0 additions and 3 deletions.
3 railties/lib/rails/generators/rails/app/templates/config/application.rb
View file
@@ -27,9 +27,6 @@ class Application < Rails::Application
# Custom directories with classes and modules you want to be autoloadable.
# config.autoload_paths += %W(#{config.root}/extras)

# Activate observers that should always be running.
# config.active_record.observers = :cacher, :garbage_collector, :forum_observer

# Set Time.zone default to the specified zone and make Active Record auto-convert to this zone.
# Run "rake -D time" for a list of tasks for finding time zone names. Default is UTC.
# config.time_zone = 'Central Time (US & Canada)'

6 comments on commit 775ddf2

@wpp
Copy link

@wpp wpp commented on 775ddf2 Aug 8, 2012

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could someone elaborate on why observer are no longer important enough?

@dhh
Copy link
Member Author

@dhh dhh commented on 775ddf2 Aug 9, 2012

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I consider observers to be a minority use case at this point. They're like aspects, you don't know what they're watching and why when you look at existing code. It's generally better to have explicit calls in filters or directly in controllers and models.

@dhh
Copy link
Member Author

@dhh dhh commented on 775ddf2 Aug 9, 2012

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For example, I used to use Observers to trigger when emails would be sent on signup and we had the idea of the Sweeper for caches. Now I just let the controllers send out emails (please don't use after_create for that!) and key-based expiration has eliminated the need for manual cache expiration.

In fact, if someone showed me observers today, I'd probably say "that'd make a nice plugin, but it's not core material".

@wpp
Copy link

@wpp wpp commented on 775ddf2 Aug 10, 2012

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In your example, as far as I understand it, I would agree that moving from the Observer to the controller is a clearer approach.

But lets say I want to implement a Notifications System,
which creates notifications for the creation of a couple of models (posts, comments, etc).
I much prefer the idea of an Observer which observes these models instead of duplicating the same callback in each of them.

@oelmekki
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(I see dead trolls coming)

@dhh do you intend to also remove the observer layer from core, in the future, or will it stay as is, just not mentionned in generated config files ?

@dhh
Copy link
Member Author

@dhh dhh commented on 775ddf2 Aug 10, 2012

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@oelmekki The current plan is to split observers into a plugin. Should be done soon in master.

@wpp I don't think an Observer is a good solution in that case either. Use a controller concern module that encapsulates the pattern on that side.

Please sign in to comment.