joshmcarthur/inquest — pull request #4 by joshmcarthur (2013-04-05 11:28:54+00:00)
Title: Feature/notifications

I know that an implementation of Notifications has already been merged, but I feel that this is a better way of doing it. The old approach worked, but not in a very elegant way - it was observing the model itself, and trying to react to changes that weren't always all that model-based - it didn't feel like it was going to be that scalable.

This new approach piggybacks on the creation of `PublicActivity::Activity` objects created for the activity log. It matches notification rules based on the `trackable` object attached to the activity (`Question`, `Answer`, etc.), and the `key` - normally this is `model_name.action` - e.g. `question.create`. It then manually triggers any matching notification rules. The assumption is, if the activity is being created, the model must have changed accordingly.

This approach should be much easier to scale, as it will more or less work with any model that is observed by `PublicActivity`. For now, just the notifications that were already implemented in the previous pull request have been implemented in this one. All the specs are passing.

FYI, in order to get this working, I also had to make some adjustments to the `disclosure` gem, which has been released as [version 0.7 on rubygems](https://rubygems.org/gems/disclosure). The specs are also passing for that gem, as the main change involved not restricting the notifier class name to a predefined list, and instead allowing any defined class to be used in a rule - the impact of this being that you then have to implement your own method of reacting to these rules, since I can't bootstrap classes that `disclosure` doesn't know about - e.g. in Inquest, I use `PublicActivity` to react, instead of `disclosure`'s built-in model observers.