kezabelle / django-stagesetting

dynamic site settings, based on Django Forms, and optionally the Django Admin

django-stagesetting 0.5.0

An application for managing site configuration through normal Django forms, and thus through the admin site.

Release	Status
stable (0.5.0)
master

Pre-requisites

The following versions are tested:

• Python 2.7, or 3.3+
• Django 1.7+

Installation

First up, you need to install it (via pip as usual):

pip install django-stagesetting==0.5.0

Once that's downloaded, add the package to your INSTALLED_APPS in your settings:

INSTALLED_APPS = (
    # ...
    'stagesetting',
    # ...
)

do a migrate:

python manage.py migrate stagesetting

Add a STAGESETTINGS dictionary to your project's settings:

STAGESETTINGS = {
    'SETTING_NAME': '...',
    'ANOTHER_SETTING_NAME': '...',
}

The setting collection name is the dictionary key, so must be unique.

Writing settings

Settings may be created in a number of ways, the simplest of which is to provide a dictionary as the value:

STAGESETTINGS = {
    'MY_SETTING': {
        'an_example-datetime': datetime.today(),
        'a_date': date.today(),
        'time_now': time(4, 23),
        'boolean_field': False,
        'plain_text': 'char field',
        'decimal': Decimal('3.25'),
        'float': 2.3,
    }
}

where possible, this will auto-generate a Form class for you, choosing sensible defaults for the field variants where possible.

The other option is for the value to be a list or a tuple, where the first item represents a form (either a dictionary as above, OR the dotted.path.to.a.Form.Class if you need custom validation) and the second, optional item is the default data. The following should all be valid:

STAGESETTINGS = {
    'AUTO_GENERATED': [{
        'datetime': datetime.today(),
    }],
    'IMPORT_A_FORM': ['myapp.forms.MyForm'],
    'IMPORT_WITH_DEFAULT': ['myapp.forms.MyForm', {'default': 'data'}],
    'AUTO_GENERATED_WITH_OTHER_DEFAULTS': [{
        'datetime': datetime.today(),
    }, {'default': 'data'}],
}

A simple configuration form (for the dotted.path.Format) might look like:

from django.core.exceptions import ValidationError
from django.forms import Form, DateField

class DateForm(Form):
    start = DateField()
    end = DateField()

    def clean(self):
        cd = self.cleaned_data
        if 'start' in cd and 'end' in cd and cd['start'] > cd['end']:
            raise ValidationError("Start date cannot be after end date")
        return cd

As you can see, it really is just a normal Form. Internally, this form's cleaned_data will be converted into JSON before being saved to the database. It will get re-converted to proper Python values when pulled out of the database, by going through the given Form class's validation again, including converting to rich values like model instances.

Python types which can be detected

When detecting a dictionary as the value and auto-generating a form, the following translations will be applied:

• None becomes NullBooleanField
• datetime.datetime becomes DateTimeField
• datetime.date becomes DateField
• datetime.time becomes TimeField
• datetime.timedelta becomes DurationField
• decimal.Decimal becomes DecimalField
• float becomes FloatField
• True or False become BooleanField
• int becomes IntegerField
• uuid.UUID becomes UUIDField or RegexField, depending on the Django version
• list and tuple become MultipleChoiceField
• collections.OrderedDict, set, frozenset, and dict become ChoiceField
• models.Model instances become ModelChoiceField
• models.QuerySet becomes ModelMultipleChoiceField
• strings become one of the following, depending on what checks they pass:
  • GenericIPAddressField
  • URLField
  • EmailField
  • SlugField
  • CharField
  • IntegerField
  • DecimalField
  • UUIDField (or RegexField, depending on the Django version)
  • DateTimeField
  • DateField
  • TimeField
• Some strings are really special, and will instead turn into one of the following:
  • if the string == STATIC_URL or STATICFILES_STORAGE the field will be a ChoiceField whose options are all the files found by the project's STATICFILES_FINDERS.
  • if the string == MEDIA_URL``or ``DEFAULT_FILE_STORAGE the field will be a ChoiceField whose options are all the files found by DEFAULT_FILE_STORAGE.
  • if the string starts with STATIC_URL it will be the same as using the STATIC_URL generated field, but is a regular expression for filtering to only certain files (i.e. /static/.*\.css$ would find only css files)
  • if the string starts with MEDIA_URL it will be the same as above, but for files found in DEFAULT_FILE_STORAGE.
  • if a string looks like it contains HTML, it will try to use django-bleach for sanitisation, and one of django-ckeditor, django-tinymce, django-markdown, django-pagedown, or django-epiceditor for an appropriate widget.

Usage in code

The best way to access the settings in your views is to include stagesetting.middleware.ApplyRuntimeSettings in your MIDDLEWARE_CLASSES which will ensure there is a request.stagesettings variable which can be used like so:

def myview(request):
    how_many_form_data = request.stagesetting.LIST_PER_PAGE
    allow_empty_form_data = request.stagesetting['ALLOW_EMPTY']

each setting will be a dictionary of the Form values, either the default ones or those changed in the database.

Usage in templates

If you've already got request in your template, obviously you can continue to use request.stagesettings if the middleware is wired up.

If you don't have request, or you're not using the middleware, stagesetting.context_processors.runtime_settings provides a STAGESETTING template variable which contains the exact same data.

Finally, if not using the middleware nor the context processor, there is a template tag available as a last resort. It's usage is:

{% load stagesetting %}
{% stagesetting as NEW_CONTEXT_VARIABLE %}
{{ NEW_CONTEXT_VARIABLE.SETTING_NAME.fieldname }}

Usage outside of a request

If you don't have the middleware, or are in a part of the code which doesn't have a request, you can use the wrapper object directly:

from stagesetting.models import RuntimeSettingWrapper
def my_signal_handler(sender, instance, **kwargs):
    live_settings = RuntimeSettingWrapper()
    data = live_settings.LIST_PER_PAGE

Try to keep a single RuntimeSettingWrapper around for as long as possible, rather than creating a new instance everywhere, as the object must fetch the available settings from the database the first time it needs them. It caches them for it's lifetime thereafter.

Alternatives

Other apps I know of that achieve similar things, or overlap in some obvious way. I won't judge you for using them, and I can't promise this is better. To the victor, the spoils of maintenance!

• django-constance is similar
  • uses pickle to store an arbitrary python value; stagesetting only stores stuff it can put into JSON and relies on Django Forms to inflate the JSON back into python values.
  • Has both database and redis backends; stagesetting only supports the database, though it will only do one query most of the time.
• django-dynamic-preferences by the look of it.
• django-solo as well.
• django-djconfig looks similar in principle, insofar as it uses forms?
• django-aboutconfig maybe?
• django-modelsettings looks pretty similar - define Django application settings with Django ORM models and edit them in the admin area.

If you think GitHub popularity is an indication of usage and battle-tested production-readiness, then any of the above are certainly worth considering, being much more noticed than this, my attempt.

django-stagesetting's Issues

use the `vLargeTextField` for admin inputs

If the widget == forms.TextInput, instead of using AdminTextInputWidget use a subclass which sets vLargeTextField as the CSS class, rather than vTextField

Add management command?

Discussing various config apps on IRC with @gcbirzan, was pointed out that constance has a CLI mode.
Probably a bit of a pig to implement here because every configuration is potentially multi-value, but it's an interesting notion.
At the very least a "get" command would probably be workable, which could be useful in and of itself.

One for a rainy day.

If given an OrderedDict to autogenerate a form, don't resort it.

given:

generate_form(OrderedDict([
    ('z', '1'),
    ('a', '1'),
])

don't re-sort the fields such that the order is a, z when it's clear the person (me, probably) wanted it in a specific field order (z, a)

Enumerating files is kinda slow

Use lru_cache for _get_files_in_static_storage and _get_files_in_default_storage?

Provide a way to migrate from an auto-generating form, to an actual form declaration.

given:

{'a': 1, 'b': '2'}

allow the resulting form instance to be printed to stdout as:

class MyForm(Form):
    a = fields.IntegerField()
    b = fields.CharField()

either as a method on the form, or maybe a management command.

Investigate the middleware situation under 1.10+

I suspect tests passing under 1.10+ is a little bit of a lie, as its probably not using the new MIDDLEWARE system (or shimming the necessary MiddlewareMixin)

Support detecting strings which can be coerced to decimals/dates/datetimes.

given a string of '1.0', or '2016-01-06', or '06/01/2016 00:00:00' etc as a value, try and do the right thing and create a form field instance of the right type.

For decimals it's probably just catching TypeError and continuing; for date formats it'd be best to go through the DATE_INPUT_FORMATS etc and see if it can be coerced based on the project's (or maybe just the global defaults?) configuration.

Allow extension of models etc.

I may have a need for doing per-SITE_ID config at some point soon. It'd be nice if I could rework it so the root model is abstract and concrete, and all the usages of the model are replaceable with N effort.

if defaults are given, apply them over the database settings if not there.

• create an item into the database so that defaults are persisted.
• if there are keys in the defaults which are not in the ones from the db, add the extra keys

I think this would work.