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 committed Aug 7, 2012
1 parent 7ef56d6 commit 775ddf2e69ab0bfaed17c691cf79999974d62dca
Showing with 0 additions and 3 deletions.
  1. +0 −3 railties/lib/rails/generators/rails/app/templates/config/application.rb
@@ -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

This comment has been minimized.

Show comment
Hide comment
@wpp

wpp Aug 8, 2012

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

wpp replied Aug 8, 2012

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

@dhh

This comment has been minimized.

Show comment
Hide comment
@dhh

dhh Aug 9, 2012

Member

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.

Member

dhh replied Aug 9, 2012

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

This comment has been minimized.

Show comment
Hide comment
@dhh

dhh Aug 9, 2012

Member

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".

Member

dhh replied Aug 9, 2012

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

This comment has been minimized.

Show comment
Hide comment
@wpp

wpp Aug 10, 2012

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.

wpp replied Aug 10, 2012

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

This comment has been minimized.

Show comment
Hide comment
@oelmekki

oelmekki Aug 10, 2012

(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 ?

(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

This comment has been minimized.

Show comment
Hide comment
@dhh

dhh Aug 10, 2012

Member

@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.

Member

dhh replied Aug 10, 2012

@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.