Plugin support

[ifoukarakis]

This PR is a suggestion for refactoring according to issue #27. It includes the following changes:

• [x] Define Plugin class. Plugins are small utility classes that can generate payload.
• [x] Define PluginManager that encapsulates logic for selecting the proper plugin to generate request payload.
• [x] Move Django payload generation to plugin.
• [x] Add unit tests for Django payload generation
• [x] Small change to .gitignore in order to avoid committing Pycharm files.
• [x] Move current request handling to Django middleware.

This PR should have no effect on end-users of the library. However it can be used as the basis for adding payload generation for other projects as well.

TBH, I'm not an expert in Django, so any feedback on unittests are more than welcomed!

Finally, there's a point I'd like to discuss. Django middleware caches . With the plugin mechanism in place, DjangoPlugin class might be a better candidate for moving this logic. This way Honeybadger may become agnostic to any frameworks.

[ifoukarakis]

Please note that I also had to make an ugly fix for testfixtures to work with Python 3.2

[stympy]

This is looking good to me. I'm fine with moving the current request logic to the DjangoPlugin class.

Did your original PR comment get cut off? I'm not clear on what you meant by the "open discussion" comment.

[ifoukarakis]

Hey, seems that the last part actually got cut off. My comment was that request is Django specific. So it's lifecycle management may be more suitable in Django middleware.

[stympy]

Agreed. We've tried to isolate the Rails-related stuff as much as possible in the Ruby gem, so I see no reason not to the same for Django-related stuff here.

[ifoukarakis]

Ok, I'll update current PR as soon as I find some time:)

[ifoukarakis]

Hi,

Finally managed to find some time and update the PR according to the last comment. I also included an example Django app I used to test the changes.

[stympy]

Awesome, thanks!