This form widget allows you to just display data in a rendered form, not giving the user the opportunity to change it. The initial data will just be carried through the form and showed to the user. In combination with snipped [1184](http://www.djangosnippets.org/snippets/1184/) you can make this even tamper safe. ;-)
Much stolen from base `truncate_html_words`. The difference is that this filter takes a number of characters as its argument and truncates to the nearest word boundary less than that count, rather than specifying a number of words.
I'm using Django 0.96 for a project, and the url tag does not have all the capabilities I need. I want a way to persist all or some of the GET parameters between requests. I also want a way to add to the current url a list of extra parameters, or nullify certain parameters. In this snippet I am defining 2 tags ... link_persist and link_add. It only works with Django 0.96, as the API changed ... but maybe a good soul can fix it for 1.0, as I haven't had any time available. A tip for usage: if you specify a parameter as being the empty string, or None, the parameter will be removed from the link. When you specify a parameter already available in GET, it will replace it.
Works exactly like the standard "extends" tag but enables one to fallback on a default template. This tag is LIMITED, as it falls back to the next template with the same name that DOES NOT contain "extends_default" (does NOT simulate full inheritance, just a single level). A partial solution to problems like http://jeffcroft.com/blog/2008/aug/05/default-templates-django/. MIT licensed.
I use this as the FastCGI script for authorizers with lighttpd (though I guess it should work with little change on any other webserver supporting FastCGI). I point it to the same Django project/settings as the normal responder script. As I use it to gate access to pages not served by Django, I can include those non-Django URLs in the main urls.py, connected to special authorizer view functions (in another snippet). The two key parts of the script, compared to the equivalent one for Django in the normal FastCGI Responder role, are: 1. Pass the FCGI_AUTHORIZER as the role to WSGIServer 2. Generate a PATH_INFO variable from the REQUEST_URI (FastCGI authorizers aren't given PATH_INFO, but Django needs that to match against the URLconf.)
This exception is util when you want to raise an exception but want its message be shown as a message to the user, with no error 500 or 404 pages. To use it, just append the middleware in the MIDDLEWARE_CLASSES setting and raises HttpMessage when necessary.
To make all scripts relocatable. The layout of my project is: /some/path/myproject/ /some/path/myproject/some_script /some/path/myproject/some_other_script /some/path/myproject/set_paths.py /some/path/myproject/setttings.py /some/path/myproject/lib/ # some external libraries/apps checked in with my project. /some/path/myproject/myapp/ # my apps etc. This way myproject folder can be moved anywhere on the file system, and calling right path, settings.py is used.
I needed a way to quickly get a direction of html pages templated such that another person could drop new templates in to a subdirectory and without modifying urls.py or views.py get them up and being displayed. Now, the direct_to_template view provided django.views.generic.simple can sort of do this with a urlpattern like: `url(r'^(?P<template>.*\.html)$', direct_to_template)` But that means your templates, no matter what level in the url hierarchy they are reached at, have to be defined at the root of a template directory. I wanted them retrieved from a specific subdirectory instead so I could provide a little wall for them. Hence this snippet. To use you would have url pattern that looked like: `url(r'^foo/(?P<template>.*\.html)$', direct_to_template, {'subdir' : 'subdir/'}),` Which will template any url that matches <parent url>/foo/bar.html for any 'bar'. The problem is if this is a sub-url pattern match this is going to look for the template "bar.html" when we may actually want it to get the template "<parent url>/foo/bar.html"
A tag that parses args ang kwargs like the url tag. {% get_with_args_and_kwargs somevar,"sometext",kwarg1=someothervar %}
**So you can upload rectangular pictures but still have square thumbnails.** "Scale to **fill**" instead of the out of the box "scale to **fit**" you get with `Image.thumbnail`
This allows various implementations of a common interface to be loaded. Back end modules can be specified in settings.py, and from there be loaded and treated polymorphically by an application.
I needed a quick way to send e-mails to other people involved in a project when I committed code - so that designers would know that templatetag *x* was available (or fixed), etc - and am really fond of how [unfuddle](http://unfuddle.com/) handles their subversion notifications. This isn't nearly as polished as theirs, but I figured it was a good place to start. Hope someone else finds this as handy as I have.
This is a light-weight flash implementation. Instead of hitting the database it uses cookies. The messages are shown to the user only once, after that the cookies are deleted. I tested it on Google App Engine, but it should work on vanilla Django as well, there's no GAE specific code. To set up, add `"path.to.flash.Middleware"` to the `MIDDLEWARE_CLASSES` list. Also add `'path.to.flash.context_processor'` to the `TEMPLATE_CONTEXT_PROCESSORS` list. In your views, import and call `flash_error(msg)` and `flash_notice(msg)` passing the message that you want to show. In your base template use this mark up: {% if flash.notice %} <div id="flash_notice"> <p>{{ flash.notice }}</p> </div> {% endif %} {% if flash.error %} <div id="flash_error"> <p>{{ flash.error }}</p> </div> {% endif %} And finally, add this to your CSS file changing colours as necessary: #flash_error { margin-top: 30px; padding: 20px; background-color: #FFCCCC; border: solid 1px #CC0000; } #flash_notice { margin-top: 30px; padding: 20px; background-color: #CCFFCC; border: solid 1px #00CC00; } #flash_error p, #flash_notice p { margin: 0px; } Please comment if you notice any FUs. I'm new to Django and will appreciate any feedback.
The @cache_holding decorator works in a per-function base, you can specify a list of models or just a model and the second argument is the time in seconds to be cached. You can modify the proxy class by a keyword argument so you can do cache to all kind of things, also if you want to use a prefix as key + the hash value you can specify the prefix keyword argument.
This accepts values such as $1,000,000 and stores them to the database as integers. It also re-renders them to the screen using the django.contrib.humanize.intcomma method which takes 1000000 and turns it into 1,000,000. Useful for large currency fields where the decimals aren't really necessary.