Log in a user without requiring credentials
Rather than requiring a dummy backend (which I have seen some people do), use this method to log in a user without requiring their credentials.
- authentication
- user
- login
Snippet List
MultiFormWizard
This is an extended version of the FormWizard which allows display of multiple forms per step and allows usage of ModelForms with initial objects
- multiple
- forms
- form
- wizzard
- multi-form-per-step
Python Calendar wrapper template tag
This tag gives you an iterable Python [Calendar object](http://docs.python.org/library/calendar.html) in your template namespace. It is used in the [django-calendar](http://github.com/dokterbob/django-agenda) project. Use it as follows in your template: {% get_calendar for <month_number_or_variable> <year_or_variable> as calendar %} <table> <tr> <th>Mon</th> <th>Tue</th> <th>Wed</th> <th>Thu</th> <th>Fri</th> <th>Sat</th> <th>Sun</th> </tr> {% for week in calendar %} <tr> {% for day in week %} <td>{{ day.day }}</td> {% endfor %} </tr> {% endfor %} </table>
- template
- tag
- date
- calendar
twitterize filter
This filter links twitter user names prefixed with '@', hash tags, and URLs. Usage example: `{{var|twitterize}}` Note: Do not use this in conjunction with the urlize filter. Twitterize does this for you.
- filter
- hash-tags
- @replies
Naked CSS Day TemplateTag
This TemplateTag simply returns a True when it is Naked CSS Day allowing you to hide your CSS or display a custom message on that date. Allows allows for parameters should the date change (again).
- templatetag
- css
- nakedcss
- naked
Complex Form Preview
Problem ======= The FormPreview class provided by contrib.formtools helps automate a common workflow. You display a form, then force a preview, then finally allow a submit. If the form gets tampered with, the original form gets redisplayed. Unfortunately, this class can only be used when you have an html form that is backed by exactly one Django form. No formsets, no html forms backed by more than one Django form. Solution ======== I was asked to create exactly this sort of workflow for a highly complex form + formset. The ComplexFormPreview class provides a base class to help with this problem. As with FormPreview, you must override a few functions. Code ==== The abstract ComplexFormPreview class can live anywhere on your python path. Import it and subclass is exactly like you would contrib.formtools FormPreview. The self.state dictionary is passed to all response calls as the context for your templates. Add any objects you need in your template to this dictionary. This includes all forms, formsets, and any additional variables you want in your template context. Override the parse_params if you need to get any args/kwargs from your url. Save these values in self.state if you want them in your template context. Override the init_forms method to do setup for all of your forms and formsets. Save all your forms in self.state. You should provide a unique prefix for all forms and formsets on the page to avoid id collisions in html. *VERY IMPORTANT NOTE*: init_forms is called with a kwargs dictionary. You need to pass **kwargs to all of your form definations in init_forms. This is how the POST data is going to be passed to your forms and formsets. *VERY IMPORTANT NOTE No. 2*: all of the validation is handled inside the class - all forms will be found and validated, and we will only proceed when everything is found to be valid. This means that you can use the class as a view directly, or provide a thin wrapper function around it if you want. Override the done method to handle what should be done once your user has successfully previewed and submitted the form. Usually, this will involve calling one or more save() calls to your various forms and formsets. Because you now have multiple forms, the default contrib.formtools templates don't work. You must make custom templates that reference all of your various forms. The stage_field, hash_field, and hash_value fields are used exactly like the formtools examples. Follow the basic layout demonstrated in the example templates, and substitute your custom forms for the default form. Example views.py ================ The views.py demonstrated here has many hooks into my project, including using some [complex formset classes](http://www.djangosnippets.org/snippets/1290/). It won't work for you without being customized, but it will demonstrate how to override the default ComplexFormPreview.
- form
- preview
- formset
- formtools
Resolve URLs to view name
This snippet suplies a resolve_to_name function that takes in a path and resolves it to a view name or view function name (given that the path is actually defined in your urlconf). Example: === urlconf ==== urlpatterns = patterns('' (r'/some/url', 'app.views.view'), (r'/some/other/url', 'app.views.other.view', {}, 'this_is_a_named_view'), ) === example usage in interpreter === >>> from some.where import resolve_to_name >>> print resolve_to_name('/some/url') 'app.views.view' >>> print resolve_to_name('/some/other/url') 'this_is_a_named_view'
- view
- url
- resolve
- name
Painless link to admin change view for a given object
Since the admin URLs refactoring, you can easily link to the admin change view thanks to named URLs. I just discovered it, hope it helps!
- urls
- admin
Include entire networks in INTERNAL_IPS setting
A simple addition to the settings.py file of your project to allow you to easily specify entire network ranges as internal. This is especially useful in conjunction with other tools such as the [Django Debug Toolbar](http://github.com/robhudson/django-debug-toolbar/tree/master). After you set this up, the following test should pass test_str = """ >>> '192.168.1.5' in INTERNAL_IPS True >>> '192.168.3.5' in INTERNAL_IPS FALSE """ Requirements ------------ * The [IPy module](http://software.inl.fr/trac/wiki/IPy) Acknowledgements ---------------- Jeremy Dunck: The initial code for this idea is by Jeremy and in [Django ticket #3237](http://code.djangoproject.com/ticket/3237). I just changed the module and altered the use of the list superclass slightly. I mainly wanted to put the code here for safe keeping. Thanks Jeremy!
- settings
- ip-addresses
- cidr
- internal-ips
Fuzzy Date Diff Template Filter
Pass in a date and you get a humanized fuzzy date diff; e.g. "2 weeks ago" or "in 5 months". The date you pass in can be in the past or future (or even the present, for that matter). The result is rounded, so a date 45 days ago will be "2 months ago", and a date 400 days from now will be "in 1 year". Usage: * `{{ my_date|date_diff }}` will give you a date_diff between `my_date` and `datetime.date.today()` * `{{ my_date|date_diff:another_date }}` will give you a date_diff between `my_date` and `another_date` Make sure to install this as a template tag and call `{% load date_diff %}` in your template; see the [custom template tag docs](http://docs.djangoproject.com/en/dev/howto/custom-template-tags/) if you don't know how to do that.
- template
- filter
- date
- humanize
Saving passwords for other services (semi-)securely in a database
I've often found myself wanting to store passwords for other web services (e.g. maillist managers, IMAP accounts, IM accounts etc) for use by a web application, but have not wanted to hard-code them in `settings.py` or store them as plaintext in the database. This uses the [pycrypto][] library to encrypt each bit of information using the concatenation of a salt value and the SECRET_KEY value from your `settings.py`, hopefully leading to a bit more security and flexibility. [pycrypto]:http://www.dlitz.net/software/pycrypto/ You'll probably want to add some views to let people edit these things as I can't find a way to make the admin interface play nicely with it. **Example usage:** In [1]: p = Password( name='IMAP account', slug='imap', username='example', password='password', host='imap.gmail.com' ) In [2]: p.host Out[2]: 'imap.gmail.com' In [3]: p.e_host Out[3]: '6wdyMDKYy8c=$YXw6t/Q9wI[...]' In [4]: p.save()
- password
- crypto
BetterForm with fieldsets and row_attrs
**NOTE**: Further development of this snippet will take place in the [django-form-utils](http://launchpad.net/django-form-utils) project. This snippet provides BetterForm and BetterModelForm classes which are subclasses of django.forms.Form and django.forms.ModelForm, respectively. BetterForm and BetterModelForm allow subdivision of forms into fieldsets which are iterable from a template, and also allow definition of row_attrs which can be accessed from the template to apply attributes to the surrounding container of a specific form field. It's frequently said that a generic form layout template is a pipe dream and in "real usage" it's necessary to manually layout forms, but in my experience the addition of fieldsets and row_attrs, plus a competent CSS designer, make it possible to create a generic template that can render useful production form markup in 95+% of cases. Usage: class MyForm(BetterForm): one = forms.CharField() two = forms.CharField() three = forms.CharField() class Meta: fieldsets = (('main', {'fields': ('two',), 'legend': ''}), ('Advanced', {'fields': ('three', 'one'), 'description': 'advanced stuff'})) row_attrs = {'one': {'style': 'display: none'}} Then in the template: {% if form.non_field_errors %}{{ form.non_field_errors }}{% endif %} {% for fieldset in form.fieldsets %} <fieldset class="fieldset_{{ fieldset.name }}"> {% if fieldset.legend %} <legend>{{ fieldset.legend }}</legend> {% endif %} {% if fieldset.description %} <p class="description">{{ fieldset.description }}</p> {% endif %} <ul> {% for field in fieldset %} {% if field.is_hidden %} {{ field }} {% else %} <li{{ field.row_attrs }}> {{ field.errors }} {{ field.label_tag }} {{ field }} </li> {% endif %} {% endfor %} </ul> </fieldset> {% endfor %}
- fieldset
- form
- layout
"Partial Templates" - an alternative to "include"
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 **partials** folder. The **.html** extension will be appended to the file name. The file has to be in one of template paths accessible to the loader) and rendered with **data** as its context. The data is available in the template as an `item` context variable. You can find more information in the [relevant Django documentation](http://docs.djangoproject.com/en/dev/howto/custom-template-tags/#howto-custom-template-tags)
- template
- tag
- templates
- tags
- partial
- include
- partials
ManyToManyField no syncdb
**Sumary** M2M relation without creating table. Normally you should specify m2m only in *one* model, thus widgets for many-to-many relations will be displayed inline on whichever model contains the actual reference to the ManyToManyField. But if you want to be able to have widgets displayed on both form you need some tricks, for example using intermediary-models can help, but you will not get multiselect widget (and in case of inlining extra = multi). Also you can write your own form which takes care about adding widget (just 1 line) and setting default values and saving it (more than few lines of code). If you try ManyToManyField with same db_table specified, the only problem will be in syncdb (it will try to create two identical tables) and the only thing our class does is preventing creation of table for M2M, so in one model you should use ManyToManyField and in another ManyToManyField_NoSyncdb with the same db_table argument. **Example** So to have M2M widgets in both forms you can write: class User(models.Model): #... groups = ManyToManyField('Group', related_name='groups', db_table=u'USERS_TO_GROUPS') class Group(models.Model): #... users = ManyToManyField_NoSyncdb(User, related_name='users', db_table=u'USERS_TO_GROUPS')
- model
- field
- manytomany
- manytomanyfield
- syncdb
Unobtrusive comment moderation, updated for Django 1.0
This is the "unobtrusive comments moderation" code from http://www.djangosnippets.org/snippets/112/ , but updated so it works properly with Django 1.0. There are only a few small changes reflecting changes in the comments, contenttypes, and signals APIs. For full background, see the original snippet: http://www.djangosnippets.org/snippets/112/
- akismet
- comments
- moderation