| Author: | Keryn Knight |
|---|---|
| Version: | 0.2.0 |
| Release | Status |
|---|---|
| stable (0.2.0) | |
| master |
Sections
intercooler_helpers is a small reusable app for Django which provides a
few improvements for working with Intercooler.js.
It providea a middleware which extracts relevant Intercooler.js data from the
querystring, and attaches it to the request as a separate QueryDict (ie: it
behaves like request.POST or request.GET)
It also provides a small middleware for changing request method based on either the
query string (_method=PUT) or a request header(X-HTTP-Method-Override: PUT)
Between them, they should capture all the incoming Intercooler.js data on which the server may act.
This application depends on django-intercoolerjs which provides a copy of Intercooler.js bundled up for use with the standard Django staticfiles application.
You can grab 0.2.0 from PyPI like so:
pip install django-intercooler-helpers==0.2.0
Or you can grab it from GitHub like this:
pip install -e git+https://github.com/kezabelle/django-intercoolerjs-helpers.git#egg=django-intercoolerjs-helpers
You need to add intercooler_helpers.middleware.IntercoolerData to your
MIDDLEWARE_CLASSES (or MIDDLEWARE on Django 1.10+).
You may optionally want to add intercooler_helpers.middleware.HttpMethodOverride
as well, if you don't already have a method by which to fake the HTTP Method change.
If you're using <meta name="intercoolerjs:use-actual-http-method" content="true"/>
then you don't need HttpMethodOverride at all.
To install all the middleware, you want something like:
# MIDDLEWARE = ... for newer Django MIDDLEWARE_CLASSES = ( # ... 'intercooler_helpers.middleware.HttpMethodOverride', 'intercooler_helpers.middleware.IntercoolerData', 'intercooler_helpers.middleware.IntercoolerRedirector', # ... )
HttpMethodOverride and IntercoolerData ought to be near the top of the iterable, as they both make use of process_request(request).
IntercoolerRedirector ought to be near the bottom, as it operates on process_response(request, response) and you probably want to convert the response to a client-side redirect at the earliest opportunity.
A brief overview of the public API provided so far:
For fully correct detection of Intercooler.js requests, you can call
request.is_intercooler().
Behind the scenes, it uses request.maybe_intercooler() to
detect whether ic-request was present, indicating it may have been a
valid Intercooler.js request, and also checks request.is_ajax()
To parse the Intercooler-related data out of the query-string, you can use
request.intercooler_data (not a method!) which is a QueryDict and should
behave exactly like request.GET - It pulls all of the ic-* keys out
of request.GET and puts them in a separate data structure, leaving
your request.GET cleaned of extraenous data.
request.intercooler_data is a lazy data structure, like request.user,
so will not modify request.GET until access is attempted.
The following properties exist, mapping back to the keys mentioned in the Intercooler.js Reference document
request.intercooler_data.urlreturns anamedtuplecontaining- returns the
ic-current-url(converted viaurlparse) orNone - A Django
ResolverMatchpointing to the view which made the request (based onic-current-url) orNone
- returns the
request.intercooler_data.elementreturns anamedtuplecontainingic-element-nameorNoneic-element-idorNone
request.intercooler_data.id- the
ic-idwhich made the request. an ever-incrementing integer.
- the
request.intercooler_data.request- a boolean indicating that it was an Intercooler.js request. Should always
be true if
request.is_intercooler()said so.
- a boolean indicating that it was an Intercooler.js request. Should always
be true if
request.intercooler_data.target_idic-target-idorNone
request.intercooler_data.triggerreturns anamedtuplecontainingic-trigger-nameorNoneic-trigger-idorNone
request.intercooler_data.prompt_value- If no
ic-prompt-namewas given and a prompt was used, this will contain the user's response. Appears to be undocumented?
- If no
request.changed_methodis a boolean indicating that the request was toggled from being aPOSTto something else (one ofGET,HEAD,POST,PUT,PATCH,DELETE,OPTIONS... though why you'd want toPOSTand have it act as aGETis beyond me. But that's your choice)request.original_methodif either_method=XorX-HTTP-Method-Override: Xcaused the request to change method, then this will contain the original request. It should always bePOSTrequest.methodwill reflect the desired HTTP method, rather than the one originally used (POST)
If a redirect status code is given (> 300, < 400), and the request originated from Intercooler.js (assumes IntercoolerData is installed so that request.is_intercooler() may be called), remove the Location header from the response, and create a new HttpResponse with all the other headers, and also the X-IC-Redirect header to indicate to Intercooler.js that it needs to do a client side-redirect.
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
A barebones demo is provided. It assumes you're using something like virtualenv and virtualenvwrapper but you can probably figure it out otherwise:
mktmpenv --python=`which python3` pip install -e git+https://github.com/kezabelle/django-intercooler-helpers.git#egg=django-intercooler-helpers
Then probably:
cd src/django-intercooler-helpers python demo_project.py runserver
It shows off a few of the same demos that the Intercooler.js website does.
Please do!
The project is hosted on GitHub in the kezabelle/django-intercooler-helpers 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.
TODO.
It's FreeBSD. There's should be a LICENSE file in the root of the repository, and in any archives.