README.md in wisper-1.2.0 vs README.md in wisper-1.2.1

- old
+ new

@@ -1,70 +1,65 @@ # Wisper -Simple pub/sub for Ruby objects +Wisper is a Ruby library for decoupling and managing the dependencies of your +Ruby objects using Pub/Sub. [![Code Climate](https://codeclimate.com/github/krisleech/wisper.png)](https://codeclimate.com/github/krisleech/wisper) [![Build Status](https://travis-ci.org/krisleech/wisper.png?branch=master)](https://travis-ci.org/krisleech/wisper) -While this is not dependent on Rails in any way it was extracted from a Rails -project and can used as an alternative to ActiveRecord callbacks and Observers. +Wisper was extracted from a Rails codebase but is not dependant on Rails. -The problem with callbacks and Observers is that they always happen. How many -times have you wanted to do `User.create` without firing off a welcome email? +It is commonly used as an alternative to ActiveRecord callbacks and Observers +to reduce coupling between data and domain layers. -It is also super useful for integrating web socket notifications, statistics -and activity streams in to your controller layer without coupling them to your -models. - ## Installation Add this line to your application's Gemfile: ```ruby -gem 'wisper', '~>1.0.0' +gem 'wisper', '~>1.2.0' ``` ## Usage -Any class with the Wisper module included can broadcast events to subscribed -listeners. Listeners are added, at runtime, to the publishing object. +Any class with the `Wisper::Publisher` module included can broadcast events +to subscribed listeners. Listeners subscribe, at runtime, to the publisher. ### Publishing ```ruby class MyPublisher include Wisper::Publisher def do_something # ... - publish(:done_something, self) + publish(:done_something) end end ``` -When the publisher publishes an event it can pass any number of arguments which -are passed on to the listeners. +When a publisher broadcasts an event it can pass any number of arguments which +are to be passed on to the listeners. ```ruby -publish(:done_something, self, 'hello', 'world') +publish(:done_something, 'hello', 'world') ``` ### Subscribing #### Listeners -Any object can be a listener and by default they are only subscribed to events -they can respond to. +Any object can be a listener and only receives events it can respond to. ```ruby my_publisher = MyPublisher.new my_publisher.subscribe(MyListener.new) ``` #### Blocks -Blocks are subscribed to single events. +Blocks are subscribed to single events only. ```ruby my_publisher = MyPublisher.new my_publisher.on(:done_something) do |publisher| # ... @@ -128,30 +123,37 @@ ```ruby class PlayerJoiningTeam include Wisper::Publisher - def execute(player, team) + attr_reader :player, :team + + def initialize(player, team) + @player = player + @team = team + end + + def execute membership = Membership.new(player, team) if membership.valid? membership.save! - email_player(player, team) - assign_first_mission(player, team) + email_player + assign_first_mission publish(:player_joining_team_successful, player, team) else publish(:player_joining_team_failed, player, team) end end private - def email_player(player, team) + def email_player # ... end - def assign_first_mission(player, team) + def assign_first_mission # ... end end ``` @@ -193,15 +195,16 @@ ``` ## Global listeners If you become tired of adding the same listeners to _every_ publisher you can -add global listeners. They receive all published events which they can respond +add listeners globally. They receive all broadcast events which they can respond to. -However it means that when looking at the code it will not be obvious that the -global listeners are being executed in additional to the regular listeners. +Global listeners should be used with caution, the execution path becomes less +obvious on reading the code and of course you are introducing global state and +'always on' behaviour. This may not desirable. ```ruby Wisper.add_listener(MyListener.new) ``` @@ -233,22 +236,21 @@ ```ruby post_creater.subscribe(PusherListener.new, :on => :create_post_successful) ``` -## Mapping event to a different method +## Mapping an event to a different method By default the method called on the subscriber is the same as the event broadcast. However it can be mapped to a different method using `:with`. ```ruby report_creator.subscribe(MailResponder.new, :with => :successful) ``` -In the above case it is pretty useless unless used in conjuction with `:on` -since all events will get mapped to `:successful`. Instead you might do -something like this: +This is pretty useless unless used in conjuction with `:on`, since all events +will get mapped to `:successful`. Instead you might do something like this: ```ruby report_creator.subscribe(MailResponder.new, :on => :create_report_successful, :with => :successful) ``` @@ -273,12 +275,12 @@ .on(:failure) { |post| render :action => :edit, :locals => :post => post } ``` ## RSpec -Wisper comes with a method for stubbing event publishers so that you can create isolation tests -that only care about reacting to events. +Wisper comes with a method for stubbing event publishers so that you can create +isolation tests that only care about reacting to events. Given this piece of code: ```ruby class CodeThatReactsToEvents @@ -326,10 +328,20 @@ ## Compatibility Tested with MRI 1.9.x, MRI 2.0.0, JRuby (1.9 and 2.0 mode) and Rubinius (1.9 mode). + See the [build status](https://travis-ci.org/krisleech/wisper) for details. + +## Running Specs + +``` +rspec spec +``` + +There is both a `Rakefile` and `Guardfile`, if you like you prefer to run the +specs using `guard-rspec` or `rake`. ## License (The MIT License)