Cache Decorator
A cache decorator.
- caching
A cache decorator.
This snippet defines a Widget that is very similar to the **SelectDateWidget** located in django.forms.extras.widgets. The main difference however is that it works with Times instead of Dates. The SelectTimeWidget supports both 24-hr and 12-hr formats, and flexible time increments for hours, minutes and seconds. Sample usage is illustrated below: # Specify a basic 24-hr time Widget (the default) t = forms.TimeField(widget=SelectTimeWidget()) # Force minutes and seconds to be displayed in increments of 10 t = forms.TimeField(widget=SelectTimeWidget(minute_step=10, second_step=10)) # Use a 12-hr time format, which will display a 4th select # element containing a.m. and p.m. options) t = forms.TimeField(widget=SelectTimeWidget(twelve_hr=True))
This module defines a template tag `{% ifactive %}` that lets you determine which page is currently active. A common use case is for highlighting the current page in a navigation menu. It uses the same syntax for specifying views as the `{% url %}` tag, and determines whether a particular page is active by checking if the same view is called with the same arguments, instead of just comparing URLs. As a result, it can handle cases where different URLs map to the same view. Example usage: <a {% ifactive request page1 %}class='active'{% endifactive %} href='{% url page1 %}'>Page 1</a> <a {% ifactive request page2 %}class='active'{% endifactive %} href='{% url page2 %}'>Page 2</a> ... <a {% ifactive request pageN %}class='active'{% endifactive %} href='{% url pageN %}'>Page N</a> It also can be extended to further reduce the amount of repetitive code. For instance, you could write a template tag that has class='active' as the block contents, and always gets the variable from context['request']: def do_activeif(parser, token): "e.g. <a {% activeif page1 %} href='{% url page1 %}'>Page 1</a>" tag_args = token.contents.split(' ') view_name = tag_args[1] args, kwargs = _parse_url_args(parser, tag_args[2:]) return ActiveNode('request', view_name, args, kwargs, NodeList(TextNode('class="active"'))) register.tag('activeif', do_activeif) Note that you will have to add the ActiveViewMiddleware to your settings.py: MIDDLEWARE_CLASSES = ( ..., 'path.to.this.module.ActiveViewMiddleware' ) You may also want to add this template tag as a built-in, so you don't have to call `{% load %}`. In somewhere that's imported by default (e.g. where you define your views), add: from django import template template.add_to_builtins('path.to.this.module')
=== version 2 === > Parts of this code are based off of source from *davidcramer* on #django and I'd like to thank him for his assistance. Example: # forms.py ... class ForumPostForm(FieldAccessForm): class Meta: model = ForumPost class FieldAccess: moderator = FieldAccessLevel( lambda user, instance: user.get_profile().is_moderator, enable = ('approve', 'delete', 'edit') member = FieldAccessLevel( lambda user, instance: user.is_active, enable = ('edit',), exclude = ('approve', 'delete') ... # template ... <form action="" method="POST"> <table> {% for field in form %} <tr><th>{{ field.label_tag }}</th><td> {% if not field.field.disabled %} {{ field }} {% else %} {{ field.field.value }} {% endif %} </td></tr> {% endfor %} </table> <p><input type="submit" value="Update" /></p> </form> ... This class will grant or deny access to individual fields according to simple rules. The first argument must be a user object, but otherwise, this class is instantiated the same as a ModelForm. To utilize this code, inherit your form from FieldAccessForm, and create an inner class on your form called FieldAccess. Variables added to this inner class must have the same structure as that provided by the FieldAccessLevel class, which defines an access level, and the fields which apply to that access level. FieldAccessLevel takes as it's first argument a callable rule that validates this access level. That rule will be called with two arguments: 'user' (current user requesting access) and 'instance' (model instance in question). The keyword arguments to FieldAccessLevel are field groups which are used to determine which fields on this form are to be enabled and/or excluded, when the current user matches this access level. The term exclude indicates fields which are not to be rendered in the form at all. Any fields not grouped in either 'enable' or 'exclude' will be disabled by default. Superusers are always assumed to have full access. Otherwise, if a field is not specified with the FieldAccess inner class, then it is disabled by default. In other words, all users (except superusers) are denied access to all fields, unless they are specifically given access on a per-field basis. It is worth mentioning that multiple access levels can apply simultaneously, giving a user access to fields from all levels for which he matches the rule. If a user is denied access to a field, then the widget for that field is flagged as disabled and readonly. The field is also given two new attributes: a boolean 'disabled', and a 'value' containing the instanced model field. These two attributes allow a template author to have great control over the display of the form. For example, she may render the plain text value of a field instead of the disabled widget. The FieldAccess inner class also allows one to conditionally exclude fields from being rendered by the form. These exclusions operate very similarly to the standard Meta exclude option, except that they apply only to the access level in question. Note: The FieldAccess inner class may be used on both the form and the model; however, generally it makes more sense on the form. If you do use FieldAccess on both the form and model, be aware that both definitions will apply simultaneously. All access levels for which the user passes the rule will be processed, regardless of whether they were found on the form or the model.
Used for showing size of the page in human readable format and time taken to generate the page on the server. To use it, in your base template, somewhere put the line: `<!-- ____SIZE_AND_DATE_PLACEHOLDER____ -->`. May be used on production.
this snippet provides a class that can be subclassed for creating views that retain state between requests, you can read more here http://code.google.com/p/django-stateful/ your comments are welcome!
This decorator does automatic key generation and simplifies caching. Can be used with any class, not just model subclasses. Also see [Stales Cache Decorator](http://www.djangosnippets.org/snippets/1131/).
A templatetag to add [Gravatar](http://www.gravatar.com/) support for [Django comments](http://docs.djangoproject.com/en/dev/ref/contrib/comments/ "Django Comments"). Based on [this snippet](http://www.djangosnippets.org/snippets/772/) but works for everyone who comments even if they are not a registered user.
Adds an additional template dir to settings.TEMPLATE_DIRS if the request's HTTP_USER_AGENT string has the word iPhone in it. Allows you to easily create iPhone templates.
This security field is based on the perception that spambots post data to forms in very short or very long regular intervals of time, where it takes reasonable time to fill in a form and to submit it for human beings. Instead of captcha images or Ajax-based security interaction, the SecurityField checks the time of rendering the form, and the time when it was submitted. If the interval is within the specific range (for example, from 5 seconds till 1 hour), then the submitter is considered as a human being. Otherwise the form doesn't validate. Usage example: class TestForm(forms.Form): prevent_spam = SecurityField() # ... other fields ... The concept works only for unbounded forms.
This piece of code will clear the cache, whether you are using in-memory or filesystem caching.
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.
If you add a lot of custom `ModelAdmin` methods to `list_display` like I do, you know it can require a lot of repetition. Notice how adding 'checkbox' to `list_display` requires typing the method name 4 times: class ExampleAdmin(admin.ModelAdmin): list_display = ['checkbox', '__str__'] def checkbox(self, object): return '<input type="checkbox" value="%s"/>' % object.pk checkbox.short_description = mark_safe('✓') checkbox.allow_tags = True Using this decorator, the name only needs to be typed once: class ExampleAdmin(admin.ModelAdmin): list_display = ['__str__'] @add(list_display, mark_safe('✓'), 0, allow_tags=True) def checkbox(self, object): return '<input type="checkbox" value="%s"/>' % object.pk
GeoNames provides a useful data file with information about every country in the world (DjangoPeople uses this). Here's an importer that grabs the file from the web and turns it in to a list of dictionaries.
A clean and simple implementation of parsing the Accept header. It places the result in request.accepted_types. Place this middleware anywhere in the chain, as all it does is add to the request object.