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