Cheetah-style comments
For those who find the Django comments syntax tedious, this snippet enables the use of (almost) Cheetah-style comments.
- template
- comments
- cheetah
Snippet List
Pass db.Field to newforms.Widget
Deprecated. I don't use this any more. Hi, I want decimal input which uses a comma as decimal seperator. It was quite complicated, but it works. It can be used as an example how to create an own subclass of an existing db.Field class and how to pass the dbfield to the widget, and use it in its render() method. I think my snippet is too complicated, but couldn't find a better solution. If you do, please tell me.
- newforms
- i18n
sqlallall.py
A simple script to run 'manage.py sqlall' on every app in a project.
- sql
- manage.py
- sqlall
UUIDField
UUIDField is a field which stores an uuid generated by pythons new uuid module. it's included with the python 2.5 distribution by default, but if you run an older version of python you can happily copy the file from 2.5 to django/utils/uuid.py or your project directory.
- fields
- field
- uuid
Validation for 'unique' and 'unique_together' constraints (different version)
This is a slightly different and extendend version of this snippet: http://www.djangosnippets.org/snippets/260/ Unique constraints for single fields are validated in a clean_FIELD, instead of globally in the form's clean() method, so that the error messages are correctly assigned to each field. Additionally, you can specify mappings for unique_together constraints to assign those error messages to a specific field as well (instead of having them in non_field_errors(), where they would normally be.
- newforms
- forms
- validation
- unique_together
- unique
- constraints
Django & cache headers
This takes advantage of a recently added feature to django, being able to give it real functions as the view instead of having it be a string that is has to look up itself. It takes advantage of how decorators work and how `cache_control` works, normally you'd do something like this: @cache_control(private=True, public=False) def view_stuff(request): # ... return response Which is equal to doing `view_stuff = cache_control(private=True, public=False)(view_stuff)` after definition. `cache_control` is a function factory, more or less, which we use to our advantage.
- cache
- decorators
Javascript HTTP response
I've been using this along with [prototype](http://www.prototypejs.org) to make simple ajax calls. In essence you make the calls from the client with... new Ajax.Request('url',{parameters:{'someparam':$('someparam').value}}); return false; On the onsubmit event of a form, onclick or whatever. Note that the return false is important to prevent the page from reloading. Sending some javascript to be executed back to the client is then as simple as setting up your view to return: return HttpJavascriptResponse('alert("boing");') So, yeah, prototype does the real work and this class does little other than make it clear what our intentions are and reduce the opportunities for typos. But it works for me.
- ajax
- javascript
- prototype
- return
Repeat blocks with new context / simple Jinja-like macro system
A simple macro system that makes it possible to reuse previously defined blocks, optionally with a custom context, similar to the macro functionality in Jinja. It requires some workarounds/hacks because we cannot reach all the data from inside the django template system that we need, but it seems to work pretty well so far. It is, however, also pretty untested at this point, so use at your own risk. Examples: base.html: <!-- This is mandatory if you want to use the repeat-tag in a template. It should as placed as earily as possible. See below for how to mix with template inheritance. --> {% enablemacros %} <!-- Note that {{ param }} does not exist. --> {% block foo %} A standard django block that will be written to the output. {% if param %}{{ param }}{% endif %} {% endblock %} {% macro bar %} Pretty much the same thing as a django block (can even be overridden via template inheritance), but it's content will NOT be rendered per default. Please note that it ends with ENDBLOCK! {% if param %}{{ param }}{% endif %} {% endblock %} <!-- Render foo for the second time --> {% repeat foo %} <!-- Render foo bar the first time --> {% repeat bar %} <!-- Render both blocks again, and pass a parameter --> {% repeat foo with "Hello World" as param %} {% repeat bar with "Hello World" as param %} {% macro form %}do stuff with: {{ form }}{% endblock %} {% for form in all_forms %} {% repeat display %} <!-- will have access to {{ form }} {% endfor %} extend.html: <!-- {% extends %} requires that it be the first thing in a template, and if it is, everything except for block tags is ignored, so {% enablemacros %} won't work. Instead, use: --> {% extends_with_macros 'base.html' %} {% block foo %} Will override "foo" in base.html {% endblock %} {% block bar %} Will override the macro block "bar" in base.html. Whether this is defined as block or macro doesn't matter. {% endblock %} Todo: * This (both tags used) results in infinite recursion: {% extends_with_macros "somefile" %}{% enablemacros %}
- templates
- macro
- jinja
- repeat
- reuse
- variables
Default Template Loading
One of the things about Django that has always irked me is that there seems to be no standard facility for just loading a page and displaying it, simply. Yes, there is the flatpages module, but it is primarily designed for loading content from a DB. While you specify a custom template and put in junk values for the DB content, it just feels like extra, unnecessary work. Thinking about the problem some more, I borrowed from the idea of flatpages and implemented a view that will load an otherwise unmapped template off the filesystem and render it. This is very useful when converting an existing site over. Just copy your files over. No need to map anything in the URL conf or use the admin to add any flatpage entries. Since it'll render the template, too, you can even use tags and what not, so it need not be a static page.
- template
- loader
common model privacy
A BooleanField indicating privacy is common on models, but the name of the field and whether the field being True indicates private or public both may change across models. If there is more than one potentially private model, a common interface is needed. A commonly-named method would do the job with `[a for a in MyModel.objects.all() if not a.is_private()]`, but it would still retrieve private instances from the database only to filter them out. This approach puts the name of the privacy field and whether that field being True indicates private or public in a tuple attribute of the model class. A chainable method is added to all QuerySet objects. example use: class MyModel(models.Model): is_public = models.BooleanField(default=True) # ... privacy_field = ("is_public", False) \>\>\> publicMyModels = MyModel.objects.all().exclude_private() \>\>\> values = publicMyModels.values()
- models
- querysets
Automatic Paragraphs
I just converted the autop filter from Drupal (which is itself based on a Wordpress filter) from PHP to Python. I had to change the format of the regular expressions a bit and make them raw strings, but otherwise the function is unchanged. It should work exactly like the original function.
- filter
- text
- format
pygments stylize
Simple tag to enable easy parsing of inline code within a template. Usage: {% stylize "language" %}...language text...{% endstylize %}. Make sure to set the language for Pygments to parse as the first argument to the tag. You will also need to include a copy of the CSS that Pygments uses. The [Pygments](http://pygments.org/) library is required for this tag.
- pygments
- templatetags
XhtmlDegraderMiddleware
The XhtmlDegraderMiddleware class is designed to make it easier to deploy XHTML contents onto the World Wide Web. The correct MIME media type for sending XHTML is `application/xhtml+xml` -- the `text/html` media type is also acceptable provided [certain guidelines](http://www.w3.org/TR/2002/REC-xhtml1-20020801/#guidelines) are followed. The vast majority of web browsers released from 2002 onwards have good XHTML support; this includes Mozilla Firefox, Opera, and Apple Safari. Two notable exceptions are Internet Explorer 7.0 and Netscape Navigator 4.8; instead of displaying XHTML, they present the user with a download dialog instead. The role of the XHTML Degrader, then, is to automatically detect when browsers do not support XHTML, and to degrade the contents into something they're capable of rendering. **How it works** XhtmlDegraderMiddleware checks the content type of all HTTP responses. If the XHTML media type is set, the `Accept` request header is examined to determine whether the user agent actually supports XHTML. If so, the contents is sent unaltered. If not, a number of silent changes are made to make the response more friendly to XHTML-challenged browsers and web crawlers. Firstly, the `Content-Type` header is set to the HTML media type. Any XML processing instructions are removed, and a `DOCTYPE` is added if none is present. In the case of Internet Explorer, this should ensure the content is rendered in "standards compliance" mode. Empty elements are made to have a space before their trailing slash. N.B. If an HTTP response is already set to `text/html`, or set to any media type other than `application/xhtml+xml`, the middleware will have no effect. Note also that if you use GZipMiddleware, you should ensure that it appears in your MIDDLEWARE_CLASSES setting before XhtmlDegraderMiddleware, to allow the XHTML Degrader to act first.
- middleware
- xhtml
SAS70 Compliant Password Validator
Validator to verify a password is SAS70 compliant: greater than or equal to eight characters, and contains at least three out of the four characters( Uppercase, Lowercase, Number, Special Character ).
- validator
Querying on existence of a relationship
When you have two models joined by a foreign key, it's common to want to retrieve a set of objects from the "target" of the foreign key based on whether there are any objects "pointing" to them. This snippet demonstrates how to do so, using the `extra` method of the default model manager. Note that this is probably more efficient than using two ORM methods (e.g., selecting all values from one table, and using an `id__in` lookup on the other) since it does the whole thing in one query and avoids instantiating any intermediate objects.
- models
- orm
- foreign-keys