Today’s free Monday episode features a rare delving into Rails code. We take a look at a fat controller, and thin it down by identifying the model lifecycle events that are hiding inside it.
httpv://youtube.com/watch?v=6llGNfB1Z_A
This episode garnered a lot of discussion after I initially sent it out to RubyTapas subscribers. Ryan Bates posted an alternative refactoring, as did Evan Light.
[boilerplate bypath=”rubytapas-sample”]
Thank you for making this episode free Avdi, it has brought about some fun discussion on Twitter. Regarding my refactoring, it was more of an experiment to see how it could be done without using callbacks. I do think callbacks are a good use case for this.
Also, Jonas Nicklas pointed out there is a previous_changes method that dirty tracking provides. This could be used to clean up each of our refactorings.
Hi Avdi great video. Please I wanted to find out why you chose to create the methods to enable add_listener and notify_listeners etc, can we just use ActiveSupport::Notification instead since it provides a kind of light weight pub-sub.
I am looking to use ActiveSupport::Notification to communicate between my domain objects. I know another way round is ActiveRecord observers but I don’t want to use it because it will be removed from rails-4 and moved into a gem and eventually they will stop updating/maintaining the gem. So that rules it out and leaves me with ActiveSupport::Notification.
What is your thought, on using ActiveSupport::Notification for this sort of thing. Are there any implications?
Keep up the good works and thanks for the response you shall provide.
ActiveSupport::Notifications, as I understand it, is intended mainly for instrumentation and I’d rather use it for that purpose only. Also, for some problems Observer is sufficient; a full pub/sub framework isn’t really called for.
thanks.