Author: | Keryn Knight |
---|---|
Version: | 0.1.1 |
Release | Status |
---|---|
stable (0.1.1) | |
master |
Sections
Ever used Django and wished you could have a context processor which
received the existing context, along with the request, so that it could do
different things depending on the values the view provided? This does that, as
long as you're using TemplateResponse objects and not render()
or
render_to_response()
.
You can use pip to install the 0.1.1
version from PyPI:
pip install django-contextaware-processors==0.1.1
Or you can grab it from GitHub like this:
pip install -e git+https://github.com/kezabelle/django-contextaware-processors.git#egg=django-contextaware-processors
Add a new CONTEXTAWARE_PROCESSORS
setting to your project configuration. It
should be an iterable of strings representing the dotted paths to your
processors, just the same as the Django context processors are configured:
CONTEXTAWARE_PROCESSORS = ('path.to.my_processor', 'another_processor.lives.here')
Processors are executed in the order in which they are declared, and update the
original context data. The new context is given to subsequent processors, such
that the last processor above (another_processor.lives.here
) will see any
changes made by path.to.my_processor
.
In most cases, if you're using TemplateResponse
objects (or any Class
Based View which uses them for you), you want to use the provided
middleware:
MIDDLEWARE_CLASSES = ( # ... 'contextaware_processors.middleware.ContextawareProcessors', # ... )
As this makes use of process_response(request, response)
you probably want
it somewhere near the bottom, so that it modifies the context on the way out
as soon as possible. The middleware will automatically apply any processors
defined in CONTEXTAWARE_PROCESSORS
For custom situations, there is
context_processors.response.ContextawareTemplateResponse
class which
exposes an add_context_callback(callback_function)
which can be used to
apply view-specific context modifiers, though why you'd need to is not
immeidiately obvious to me ;)
If the ContextawareProcessors
middleware notices a ContextawareTemplateResponse
it
will add those defined in CONTEXTAWARE_PROCESSORS
after any previously
registered custom modifiers.
The API contract for a processor is the same as a normal context processor, but
with the addition of a context
parameter, sent as a named-kwarg.
A normal context processor looks like:
def my_processor(request): return {'MY_VALUE': 1}
While a context-aware processor looks like:
def my_processor(request, context): if 'MY_KEY' in context: return {'MY_VALUE': 2} return {'MY_VALUE': None}
A context-aware processor must return one of 3 things:
- A dictionary
to .update(...)
the existing context with,
- NotImplemented
may be used to mark it as irrelevant for the request
- For convienience, None
may also be used to skip updating the context.
The tests are run against Django 1.8 through 1.10, and Python 2.7, 3.3, 3.4 and 3.5.
If you have a cloned copy, you can do:
python setup.py test
If you have tox, you can just do:
tox
Please do!
The project is hosted on GitHub in the kezabelle/django-contextaware-processors repository.
Bug reports and feature requests can be filed on the repository's issue tracker.
If something can be discussed in 140 character chunks, there's also my Twitter account.
It's FreeBSD. There's should be a LICENSE
file in the root of the repository, and in any archives.