Feature/modelhook

[nitely]

Fixes #7

Changes:

• HookModels: allow models to be extended by adding new fields/methods to them.
• Readme: improved "Why?" section.

[coveralls]

Coverage increased (+0.06%) to 93.733% when pulling 127107a on feature/modelhook into 26ea215 on master.

[nitely]

I'm not merging this just yet, mostly coz of the lack of tests. But I'm pretty satisfy by the way this works so far.

[nitely]

shoud be self.updated_at

[nitely]

I can't decide whether this is a good or bad idea. Except for the potential clash in field names I see no downsides. It avoids resorting to oneToOneField and have N extra join (N == Number of plugins), and it makes working with forms and ordering their fields easier (or possible at all).

But I've not merged it in 3 years, so closing this.

[nitely]

I think this is a bad idea because it won't handle migrations well. We would need to ask the final user to create a concrete model, so all migrations are stored on the user project side instead of as part of django-hooks, mainly because when django-hooks is updated the migrations will be deleted. This also has major caveats, the main app will have no way to create data migrations when needed, since the migrations won't be stored in that app, but in some user custom app.