=============
This package provides support for layers of templates that can be included
in the django template path search depending on certain conditions.
Why?
----
Using layers you can provide alternative sets of templates ("skins")
depending on different contexts. For example, using the same CMS you
can, from a single code base, host different frontend designs.
Or you can use a simple randomize function for A/B testing.
How?
----
pip/easy_install this package, django_layers
Then add 'layers.middleware.LayerLoaderMiddleware' to your
MIDDLEWARE_CLASSES, e.g.
MIDDLEWARE_CLASSES = (
'layers.middleware.LayerLoaderMiddleware',
...
)
Also, add 'layers.loader.LayerLoader' to your TEMPLATE_LOADERS, e.g.
TEMPLATE_LOADERS = (
'layers.loader.LayerLoader',
...
)
Now you can start using layers.
Create the same templates as before but in stead (or on top of) storing them
in your package's templates folder, store them in a folder called
'layers/<layername>'.
E.g. you could have
mypackage/templates/mypackage/foo.html
mypackage/layers/visitor-a/mypackage/foo.html
mypackage/layers/visitor-b/mypackage/foo.html
This creates two layers, "visitor-a" and "visitor-b" and a fallback if no
layer is selected.
Additionally, create a file "layers.py" with a function "get_layers" that
will return the layer to be used, e.g.
def get_layer(request):
if request.get_host().startswith("a."):
return "visitor-a"
if request.get_host().startswith("b."):
return "visitor-b"
You can do anything you like in the "get_layer" callable, as long as you return
a layer or nothing.
When requesting Django to render the template "mypackage/foo.html", it will
render any of the three templates above depending on the request context (the
hostname used).
Why not static?
---------------
django_layers does not handle static files. Since these can be collected,
different layers could overwrite each other. This means your CSS, js, etc
needs to have a unique name and be included explicitly.
Metadata
Release files for django_layers 0.7.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 |
|---|---|---|---|---|
| django_layers-0.7.1.tar.gz | 4.1 kB | Without provenance | Details for django_layers-0.7.1.tar.gz |
Release files / django_layers-0.7.1.tar.gz
| Download URL | django_layers-0.7.1.tar.gz |
|---|---|
| Size | 4.1 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
10a0e758fbb3fe04fca787feccde014e4fc590f34650cf9ccdaf36f86527c073
|
|
BLAKE2b-256 checksum How to use checksums |
116b7767c65dce798e82d5cf7c5e2a50cb1166075d352a3fade7807c6bf4d4c1
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
Security for django_layers 0.7.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.