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

The concept

Aldryn Boilerplates aims to solve a familiar Django problem. Sometimes re-usable applications need to provide their own templates and staticfiles, but in order to be useful, these need to commit themselves to particular frontend expectations - thereby obliging the adopter to override these files in order to adapt the application to other frontends, or create a new fork of the project aimed at a different frontend setup.

It’s especially difficult to provide a rich and complete frontend for a re-usable application, because there’s a conflict between creating a useful frontend and creating an agnostic one.

The solution is to build in provision for different, switchable, frontend expectations into the re-usable application, and this is what Aldryn Boilerplates does.

On the Aldryn platform, a Boilerplate is a complete set of frontend expectations, assumptions, opinions, conventions, frameworks, templates, static files and more - a standard way of working for frontend development.

Many developers do in fact work with their own preferred standard sets of frontend tools and code for all their projects; in effect, with their own Boilerplates, even if they don’t use that name. Aldryn Boilerplates is intended to make it easier to provide support for multiple Boilerplates in res-usable applications, and to switch between them.

If users of a particular frontend framework or system would like to use it with a certain re-usable application, they now no longer need to rip out and replace the existing one, or override it at the project level every single time. Instead with Aldryn Boilerplates they can simply add the frontend files to the application, alongside the ones for existing supported Boilerplates.

A simple setting in the project tells applications that support Aldryn Boilerplates which one to use.

Using Aldryn Boilerplates

Aldryn Boilerplates doesn’t change the way regular files in templates and static are discovered - a re-usable application that supports Aldryn Boilerplates can also work perfectly well in a project that doesn’t have it installed.

However, to support Aldryn Boilerplates, your application should place Boilerplate-specific frontend files in boilerplates/my-boilerplate-name/templates/ and boilerplates/my-boilerplate-name/static/.

For example, to add support for the Standard Aldryn Boilerplate (aldryn-boilerplate-bootstrap3) to your application, place the files in boilerplates/bootstrap3/templates/ and boilerplates/bootstrap3/static/.

Hint

don’t forget to add boilerplates to Manifest.in, alongside static and templates when creating Python packages.

Note

The convention is to prefix the github repository name with aldryn-boilerplate-. Your Boilerplate could be called something like aldryn-boilerplate-mycompany-awesome. To use it in a project, you’d set ALDRYN_BOILERPLATE_NAME = 'mycompany-awesome' and put templates and static files into boilerplates/mycompany-awesome/ in Addons. ALDRYN_BOILERPLATE_NAME is set automatically on Aldryn based on "identifier": "mycompany-awesome" in boilerplate.json when submitting a boilerplate to Aldryn.

Installation

Note

aldryn-boilerplates comes pre-installed on the Aldryn Platform and ALDRYN_BOILERPLATE_NAME is set automatically.

pip install aldryn-boilerplates

Configuration

Django 1.5 - 1.7

INSTALLED_APPS = [
    ...
    'aldryn_boilerplates',
    ...
]

TEMPLATE_CONTEXT_PROCESSORS = [
    ...
    'aldryn_boilerplates.context_processors.boilerplate',
]

STATICFILES_FINDERS = [
    'django.contrib.staticfiles.finders.FileSystemFinder',
    # important! place right before django.contrib.staticfiles.finders.AppDirectoriesFinder
    'aldryn_boilerplates.staticfile_finders.AppDirectoriesFinder',
    'django.contrib.staticfiles.finders.AppDirectoriesFinder',
]

TEMPLATE_LOADERS = [
    'django.template.loaders.filesystem.Loader',
    # important! place right before django.template.loaders.app_directories.Loader
    'aldryn_boilerplates.template_loaders.AppDirectoriesLoader',
    'django.template.loaders.app_directories.Loader',
]

Now set the name of the Boilerplate you want to use in your project:

ALDRYN_BOILERPLATE_NAME = 'bootstrap3'

Django 1.8+

In general configuration stays the same but you should respect changes that were introduced by django 1.8. In particular in Django 1.8 context processors were moved from django.core to django.template.

Be sure to include aldryn_boilerplates to INSTALLED_APPS, adjust STATICFILES_FINDERS and finally configure TEMPLATES.

For TEMPLATES you need to add aldryn_boilerplates.context_processors.boilerplate to context_processors and alter loaders in the same way as we do it for Django versions prior to 1.8.

Note that in the example below we are altering the default values, so if you are using something that is custom - don’t forget to add that too.

Here is an example of a simple configuration:

INSTALLED_APPS = [
    ...
    'aldryn_boilerplates',
    ...
]

STATICFILES_FINDERS = (
    'django.contrib.staticfiles.finders.FileSystemFinder',
    'aldryn_boilerplates.staticfile_finders.AppDirectoriesFinder',
    'django.contrib.staticfiles.finders.AppDirectoriesFinder',
)

TEMPLATES = [
    {
        'BACKEND': 'django.template.backends.django.DjangoTemplates',
        'OPTIONS': {
            'context_processors': [
                'django.contrib.auth.context_processors.auth',
                'django.contrib.messages.context_processors.messages',
                'django.template.context_processors.i18n',
                'django.template.context_processors.debug',
                'django.template.context_processors.request',
                'django.template.context_processors.media',
                'django.template.context_processors.csrf',
                'django.template.context_processors.tz',
                'sekizai.context_processors.sekizai',
                'django.template.context_processors.static',
                'cms.context_processors.cms_settings',
                'aldryn_boilerplates.context_processors.boilerplate',
            ],
            'loaders': [
                'django.template.loaders.filesystem.Loader',
                'aldryn_boilerplates.template_loaders.AppDirectoriesLoader',
                'django.template.loaders.app_directories.Loader',
            ],
        },
    },
]

Adding aldryn-boilerplate support to existing packages

The recommended approach is to add a dependency to aldryn-boilerplates and to move existing static and template files to a boilerplate folder (completely remove static and templates). If you’re in the process of re-factoring your existing templates with something new, put them into the legacy boilerplate folder and set ALDRYN_BOILERPLATE_NAME='legacy' on projects that are still using the old templates. The new and shiny project can then use ALDRYN_BOILERPLATE_NAME='bootstrap3' to use the new Aldryn Bootstrap Boilerplate (aldryn-boilerplate-bootstrap3). Or any other boilerplate for that matter.

Removing static and templates has the benefit of removing likely deprecated templates from the very prominent location, that will confuse newcomers. It also prevents having not-relevant templates and static files messing up your setup.

Release History

Release History

0.7.4

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

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

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

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

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

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

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
aldryn_boilerplates-0.7.4-py2.py3-none-any.whl (17.4 kB) Copy SHA256 Checksum SHA256 2.7 Wheel Jan 27, 2016
aldryn-boilerplates-0.7.4.tar.gz (8.9 kB) Copy SHA256 Checksum SHA256 Source Jan 27, 2016

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