djangobars
An extension to allow Django to use Handlebars templates through the pybars port of Handlebars.js
Because don’t we all want to use the same templates on the client that we do on the server?
NOTE: This project is very early-stage. Try it out, leave feedback and wishes in the issues. And pull-requests welcome!
Installation
Install djangobars:
pip install djangobars
Add 'djangobars' to your installed applications.
Add a HANDLEBARS_LOADERS value to your settings module. You will probably want:
HANDLEBARS_LOADERS = ( 'djangobars.template.loaders.filesystem.Loader', 'djangobars.template.loaders.app_directories.Loader', )(optional) Add a HANDLEBARS_DIRS and/or HANDLEBARS_APP_DIRNAMES value to your setting module. By default, djangobars will search in your TEMPLATE_DIRS folder, but you can use the HANDLEBARS_DIRS value to override this behavior. For example, if you want to use both Django templates and Handlebars templates, you may want to keep the two in separate directories.
Usage
Use pretty much just as you would Django’s own built-in templates. Instead of:
from django.shortcuts import render
def my_view(request):
# View code here...
return render(request, 'myapp/index.html', {"foo": "bar"},
content_type="application/xhtml+xml")
do this:
from djangobars.shortcuts import render
def my_view(request):
# View code here...
return render(request, 'myapp/handlebar_index.html', {"foo": "bar"},
content_type="application/xhtml+xml")
And instead of:
from django.views.generic import TemplateView
class MyView (TemplateView):
template_name = 'myapp/index.html'
do this:
from django.views.generic import TemplateView
from djangobars.response import HandlebarsResponse
class MyView (TemplateView):
template_name = 'myapp/handlebar_index.html'
response_class = HandlebarsResponse
0.2.0
Update the installation instructions.
0.2.0
New dependencies on pymeta3 and pybars3.
Include partials of other templates in the project.
0.1.5
Allow arbitrary objects as context for templates.
0.1.4
Fix a bug in the app directories template loader where the path names were calling decode in Python 2 and 3.
0.1.3
Change the installation details
Pip 1.5 makes it difficult to specify installation sources outside of the PyPI. Also, this is better motivation to get these packages officially on PyPI.
0.1.2
Depend on specific forks of pymeta and pybars
0.1.1
First Release
Metadata
Release files for djangobars 0.2.1
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | Provenance | Actions |
|---|---|---|---|---|
| djangobars-0.2.1.tar.gz | 7.5 kB | Without provenance | Details for djangobars-0.2.1.tar.gz |
Release files / djangobars-0.2.1.tar.gz
| Download URL | djangobars-0.2.1.tar.gz |
|---|---|
| Size | 7.5 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
66034b5a0b4eb8af8daae9128d6faaa18f9b06353dc0c7c96778124edd0cc8c3
|
|
BLAKE2b-256 checksum How to use checksums |
ed281a79c549290f61be5349d826787c03ba9718470d6876017691e21752200f
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
Security for djangobars 0.2.1
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
No provenance found
None of the files in this release were uploaded with provenance metadata.
A note on package security
PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.
To learn more about protecting yourself from malicious actors, visit our package security documentation.