This is a pre-production deployment of Warehouse, however changes made here WILL affect the production instance of PyPI.
Latest Version Dependencies status unknown Test status unknown Test coverage unknown
Project Description

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

Release Status
stable (0.4.2)
master

Pre-requisites

The following versions are tested:

  • Python 2.7, 3.3, or 3.4
  • Django 1.7 or 1.8

Installation

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

pip install django-stagesetting==0.4.2

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:

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:

  • 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.

License

django-stagesetting 0.4.2 is available under the terms of the Simplified BSD License (alternatively known as the FreeBSD License, or the 2-clause License):

Copyright (c) 2015, Keryn Knight
All rights reserved.

Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:

1. Redistributions of source code must retain the above copyright notice, this
   list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice,
   this list of conditions and the following disclaimer in the documentation
   and/or other materials provided with the distribution.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND
ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR
ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

The views and conclusions contained in the software and documentation are those
of the authors and should not be interpreted as representing official policies,
either expressed or implied, of the FreeBSD Project.

Change log

0.4.2

  • Admin now displays pretty names for the setting keys.
  • StaticFilesChoiceField and DefaultStorageFilesChoiceField now both use an LRU cache to avoid having to enumerate the storage backends/finders repeatedly.

0.4.1

  • When generating a form from an OrderedDict, field ordering is now preserved.
  • When a form’s values are saved into the database and become stale (because the underlying form/defaults are added to), the new defaults are transparently mapped onto the value when it’s made available via the middleware, context processor or template tag.

0.4.0

  • Introduced the stagesetting template tag.
  • Settings are no longer automatically created on app ready(), instead the defaults are lazily converted when requested via a RuntimeSettingWrapper
  • Added StaticFilesChoiceField and DefaultStorageFilesChoiceField, which allow for selecting a file that already exists in the given storage.
  • When auto-generating a form, the STATIC_URL and MEDIA_URL settings are treated as special, and turned into the aforementioned fields.
  • Providing an incomplete defaults dictionary in the second parameter of a given setting’s config will now show Info messages to indicate what’s missing.
  • When auto-generating a form from a dictionary, HTML-like values will try to use one of django-ckeditor, django-tinymce, django-markdown, django-pagedown, or django-epiceditor for a widget instead of a normal textarea.
  • Added support for using django-bleach when encountering HTML-like values in an autogenerated form.
  • Added initial support for djangorestframework

0.3.2

  • Fixed error introduced in 0.3.1 when only providing a dictionary, because it turns out it wasn’t being covered by tests.

0.3.1

  • Fixed issue where providing a dictionary wasn’t treating the values as implicit defaults to be created into the database.

0.3.0

  • Added ability to auto-generate forms for configuration values which are dictionaries.

0.2.0

  • Initial release.
Release History

Release History

0.4.2

This version

History Node

TODO: Figure out how to actually get changelog content.

Changelog content for this version goes here.

Donec et mollis dolor. Praesent et diam eget libero egestas mattis sit amet vitae augue. Nam tincidunt congue enim, ut porta lorem lacinia consectetur. Donec ut libero sed arcu vehicula ultricies a non tortor. Lorem ipsum dolor sit amet, consectetur adipiscing elit.

Show More

0.4.1

History Node

TODO: Figure out how to actually get changelog content.

Changelog content for this version goes here.

Donec et mollis dolor. Praesent et diam eget libero egestas mattis sit amet vitae augue. Nam tincidunt congue enim, ut porta lorem lacinia consectetur. Donec ut libero sed arcu vehicula ultricies a non tortor. Lorem ipsum dolor sit amet, consectetur adipiscing elit.

Show More

0.4.0

History Node

TODO: Figure out how to actually get changelog content.

Changelog content for this version goes here.

Donec et mollis dolor. Praesent et diam eget libero egestas mattis sit amet vitae augue. Nam tincidunt congue enim, ut porta lorem lacinia consectetur. Donec ut libero sed arcu vehicula ultricies a non tortor. Lorem ipsum dolor sit amet, consectetur adipiscing elit.

Show More

0.3.2

History Node

TODO: Figure out how to actually get changelog content.

Changelog content for this version goes here.

Donec et mollis dolor. Praesent et diam eget libero egestas mattis sit amet vitae augue. Nam tincidunt congue enim, ut porta lorem lacinia consectetur. Donec ut libero sed arcu vehicula ultricies a non tortor. Lorem ipsum dolor sit amet, consectetur adipiscing elit.

Show More

0.3.1

History Node

TODO: Figure out how to actually get changelog content.

Changelog content for this version goes here.

Donec et mollis dolor. Praesent et diam eget libero egestas mattis sit amet vitae augue. Nam tincidunt congue enim, ut porta lorem lacinia consectetur. Donec ut libero sed arcu vehicula ultricies a non tortor. Lorem ipsum dolor sit amet, consectetur adipiscing elit.

Show More

0.3.0

History Node

TODO: Figure out how to actually get changelog content.

Changelog content for this version goes here.

Donec et mollis dolor. Praesent et diam eget libero egestas mattis sit amet vitae augue. Nam tincidunt congue enim, ut porta lorem lacinia consectetur. Donec ut libero sed arcu vehicula ultricies a non tortor. Lorem ipsum dolor sit amet, consectetur adipiscing elit.

Show More

0.2.0

History Node

TODO: Figure out how to actually get changelog content.

Changelog content for this version goes here.

Donec et mollis dolor. Praesent et diam eget libero egestas mattis sit amet vitae augue. Nam tincidunt congue enim, ut porta lorem lacinia consectetur. Donec ut libero sed arcu vehicula ultricies a non tortor. Lorem ipsum dolor sit amet, consectetur adipiscing elit.

Show More

Download Files

Download Files

TODO: Brief introduction on what you do with files - including link to relevant help section.

File Name & Checksum SHA256 Checksum Help Version File Type Upload Date
django_stagesetting-0.4.2-py2.py3-none-any.whl (36.3 kB) Copy SHA256 Checksum SHA256 py2.py3 Wheel Sep 8, 2015
django-stagesetting-0.4.2.tar.gz (34.7 kB) Copy SHA256 Checksum SHA256 Source Sep 8, 2015

Supported By

WebFaction WebFaction Technical Writing Elastic Elastic Search Pingdom Pingdom Monitoring Dyn Dyn DNS HPE HPE Development Sentry Sentry Error Logging CloudAMQP CloudAMQP RabbitMQ Heroku Heroku PaaS Kabu Creative Kabu Creative UX & Design Fastly Fastly CDN DigiCert DigiCert EV Certificate Rackspace Rackspace Cloud Servers DreamHost DreamHost Log Hosting