# Bullet Overview for Developers

This file aims to give developers a quick tour of the bullet internals, making
it (hopefully) easier to extend or enhance the Bullet gem.

## General Control Flow aka. 10000 Meter View

When Rails is initialized, Bullet will extend ActiveRecord (and if you're using
Rails 2.x ActiveController too) with the relevant modules and methods found
in lib/bullet/active_recordX.rb and lib/bullet/action_controller2.rb. If you're
running Rails 3, Bullet will integrate itself as a middleware into the Rack
stack, so ActionController does not need to be extended.

The ActiveRecord extensions will call methods in a given detector class, when
certain methods are called.

Detector classes contain all the logic to recognize
a noteworthy event. If such an event is detected, an instance of the
corresponding Notification class is created and stored in a Set instance in the
main Bullet module (the 'notification collector').

Notification instances contain the message that will be displayed, and will
use a Presenter class to display their message to the user.

So the flow of a request goes like this:

1. Bullet.start_request is called, which resets all the detectors and empties
   the notification collector
2. The request is handled by Rails, and the installed ActiveRecord extensions
   trigger Detector callbacks
3. Detectors once called, will determine whether something noteworthy happend.
   If yes, then a Notification is created and stored in the notification collector.
4. Rails finishes handling the request
5. For each notification in the collector, Bullet will iterate over each
   Presenter and will try to generate an inline message that will be appended to
   the generated response body.
6. The response is returned to the client.
7. Bullet will try to generate an out-of-channel message for each notification.
8. Bullet calls end_request for each detector.
9. Goto 1.

## Adding Notification Types

If you want to add more kinds of things that Bullet can detect, a little more
work is needed than if you were just adding a Presenter, but the concepts are
similar.

* Add the class to the DETECTORS constant in the main Bullet module
* Add (if needed) Rails monkey patches to Bullet.enable
* Add an autoload directive to lib/bullet/detector.rb
* Create a corresponding notification class in the Bullet::Notification namespace
* Add an autoload directive to lib/bullet/notification.rb

As a rule of thumb, you can assume that each Detector will have its own
Notification class. If you follow the principle of Separation of Concerns I
can't really think of an example where one would deviate from this rule.

Since the detection of pathological associations is a bit hairy, I'd recommend
having a look at the counter cache detector and associated notification to get
a feel for what is needed to get off the ground.

### Detectors

The only things you'll need to consider when building your Detector class is
that it will need to supply the .start_request, .end_request and .clear class
methods.

Simple implementations are provided by Bullet::Detector::Base for start_request
and end_request, you will have to supply your own clear method.

### Notifications

For notifications you will want to supply a #title and #body instance method,
and check to see if the #initialize and #full_notice methods in the
Bullet::Notification::Base class fit your needs.