This filter converts slashes to spaces in a a sting and then slugify's the result. However, it ignores leading and trailing slashes. For example, it can take something like this:
/some/url/with-an-existing-slug/
And turn it into this:
some-url-with-an-existing-slug
The filter was originally written to use the *curent* url as the `disqus_identifier` for Disqus comments. For example:
{{ request.META.PATH_INFO|slug_and_slash_to_dash }}
This is the snippet of rafacbd but upgraded... (http://djangosnippets.org/snippets/955/)
Now support keep the aspect ratio or not, changing the size string (x1, x0) this choice use pil.resize or pil.thumbnail.
Remember change the variable CAPS NAMES of the cleanup code.
This cleanup function get the original main image file name and create a regexp similar to "[filename]_[width]x[height]x[ratio].[ext]" and remove all thumbs.
By example if the main image is spain_rulez.jpg the script remove by example spain_rulez_100x100x1.jpg spain_rulez_200x150x0.jpg etc... etc...
This snippet makes Django templates support `break` and `continue` in loops. It is actually more powerful than the respective Python statements as it allows breaking and continuing from an outer loop, not just the innermost.
`break` and `continue` are implemented as template filters, with the input value being the loop variable. For example, to break from the current `for` loop use `forloop|break`, and to continue from the next outer loop use `forloop.parentloop|continue`.
The implementation monkeypatches Django (specifically Nodelist and ForNode) and has been tested on v1.2 with Python 2.6.
Provides python-like string interpolation.
It supports value interpolation either by keys of a dictionary or
by index of an array.
Examples:
interpolate("Hello %s.", ["World"]) == "Hello World."
interpolate("Hello %(name)s.", {name: "World"}) == "Hello World."
interpolate("Hello %%.", {name: "World"}) == "Hello %."
This version doesn't do any type checks and doesn't provide
formating support.
This is a minimal template loader for Django 1.2 or higher that loads [Jinja2](http://jinja.pocoo.org/2/) templates. It is better integrated with Django than using Jinja2 directly:
* Your view code is the same
* Unmodified generic views use it
* RequestContext and context processors still work
To use it, add the following to you `settings.py` file:
TEMPLATE_LOADERS = (
'jinja2_for_django.Loader',
)
It searches for templates in the same places as `django.template.loaders.app_directories.Loader` − that is in the `templates` directory of each installed app.
Django custom and default template tags and filters are not available. Some are the same in Jinja2, but you need to replace the others yourself. You can add global filters and variables (such as functions) in the `Loader.env.filters` and `Loader.env.globals` dicts. You can not add tags. See the [Jinja2 documentation](http://jinja.pocoo.org/2/documentation/) for more details.
Middleware class that checks the user agent against a known list of strings found in mobile devices, and if matched it then tries to determine the name of the template being rendered based on the convention of having every view use a keyword arg called "template". It then adds "mobile" to the template name and if the mobile template exists, it will override the "template" arg for the view with the mobile template name.
Writing templatetags is obnoxious. Say you have a small blurb on all your pages that shows the latest 5 comments posted to the site -- using this filter, you could write the following:
{% for comment in "comments.comment"|latest:5 %}
...display comment here...
{% endfor %}
Say you'd like to cache one of your template filters. This decorator acts sort of like memoize, caching a result set based on the arguments passed in (which are used as the cache key).
This snippet adds simple partial support to your templates. You can pass data to the partial, and use it as you would in a regular template. It is different from Django's {% include %}, because it allows you to pass a custom variable (context), instead of reusing the same context for the included template. This decouples the templates from each other and allows for their greater reuse.
The attached code needs to go into templatetags folder underneath your project. The usage is pretty simple - {% load ... %} the tag library, and use {% partial_template template-name data %} in your template. This will result in template passed as template-name to be loaded from your regular template folders.
The variables are passed in a with compatiable syntax, eg.
VAR as NAME and VAR as NAME
No limitations on the number of variables passed.
Inspired by this [terse blog post](http://www.ghastlyfop.com/blog/2008/12/strip-html-tags-from-string-python.html).
This filter was designed to simplify the stripping out of all (x)html in a given template var, while preserving some meta information from anchor, and image tags.
Why is this even useful? If you have pre-assembled portions of templates, or model fields containing html, that you want to use to populate a *search index* like [django-haystack](http://haystacksearch.org/) you can safely discard all the markup, while keeping the text that should be still searchable. Alt text, and title attributes are worth keeping!
Based on http://www.djangosnippets.org/snippets/592/, a simplified recurse template tag that will explore dict and list objects. Useful and straightforward for JSON documents (for instance from couchdb :p).
Actual usage example:
{% recursedict mydictionary %}
<ul>
{% loop %}
<li>{% if key %}<b>{{ key }}</b>: {% endif %}{% value %}</li>
{% endloop %}
</ul>
{% endrecurse %}
The main tag syntax is "recursedict var" where var is your dictionary name.
The "key" property will contain the current key, or None if the current value comes from a list (in other words the list (a, b, c) is handled like a very hypothetical {None: a, None: b, None: c} dictionary.)
{% value %} will output the current value, or recurse if the value is a list, tuple or dict.
Based fully on [snippet 1929](http://www.djangosnippets.org/snippets/1929/)
**The update is:**
It checks to see the view returns an instance of HttpResponse and returns that rather than trying to render it.
This allows you to return something like `HttpResponseRedirect('/')`, or use a normal `render_to_response` to use a different template.
*Also updates cleandict as per comment on original snippet*
In this case the 'render_template' decorator assumes there is a myview.html template. this keeps things simple and you DRY. Hope it helps.