Custom models

[benjaoming]

This fixes #28

Collect all settings in blog.settings, add simple documentation notes for settings (notice Sphinx syntax, we should add sphinx for this project soon)

Thanks bigtime to @Fantomas42 for the approach used in django-blog-zinnia for loading custom models.

[benjaoming]

This is still WIP.. gonna try to solve the odd setuptools failure in tests.

[bufke]

What are we using six for? Is it really needed?

[bufke]

Can you explain more about what this is doing? Overriding settings I suppose? But I don't see it used elsewhere in the test.py.

[benjaoming]

I force-pushed another commit, but see my comments in #43

[benjaoming]

The proper fix is in a351dcf since it's actually caused by Travis running pip 6

[benjaoming]

Wow, Github was confused by my force-push there.. first time I ever tried anything weird on pip. I was responding to your comment on previous, overwritten commit:

What are we using six for? Is it really needed?

[benjaoming]

Can you explain more about what this is doing? Overriding settings I suppose? But I don't see it used elsewhere in the test.py.

Yes, it's called by self.settings many places.

It's necessary to reload blog.settings when changing django settings. This is a common pattern because the override_settings context manager only changes and reloads django.conf.settings

[benjaoming]

After trying to implement this and playing around with various proxy and abstract models, I've concluded that it's not possible to implement this without renaming either the model which to access (the one proxying for custom settings) or renaming/moving the default database table and its accessor model (because otherwise it will name collide with the proxy model).

To put it shortly, we can't have a concrete model blog.BlogPage, inheriting from blog.BlogPageBase and then change blog.BlogPage to inherit from myapp.BlogPage - this would require a customized setup to add migrations to blog whenever the model is customized.

If we want to use blog.BlogPage as a proxy model with a configurable base, this means renaming the actual default models originally shipped as blog.BlogPage to something else like blog.BlogPageDefault and make all the FKs configurable, editing all the existing migrations.

So what I came up with is to not reinvent the wheel and instead opt for this:

https://pypi.python.org/pypi/swapper

Because Django's swappable API is considered undocumented and subject to change (although it hasn't changed for quite some time), it's probably safer to go through an application that implements whatever Django uses internally.

Closing this and trying a new PR with swapper instead...

[benjaoming]

I've edited my explanation a bit, but feel free to ask!

[benjaoming]

Just another quick update: I'm still working on this. It looks possible!

However, as with django.crontrib.auth, there might be a pitfall in the way to introduce a swappable model... i.e. you don't just swap it in the middle of something :) So swappable will continue to be a slightly misleading term :)