A few jinja2 filters like django ones
Some of this is modified from [http://www.djangosnippets.org/snippets/1062/](http://www.djangosnippets.org/snippets/1062/)
- filters
- template-filters
- jinja2
Some of this is modified from [http://www.djangosnippets.org/snippets/1062/](http://www.djangosnippets.org/snippets/1062/)
This is heavily inspired by [http://code.google.com/p/smorgasbord/](http://code.google.com/p/smorgasbord/). But that couldn't reuse an existing jinja2 Environment, nor set filters on the Environment it created. This code assumes that you have `env` declared previously in the file as your Jinja2 Environment instance. In `settings.py`, you should set KEEP_DJANGO_TEMPLATES = ( '/django/contrib/', ) so that your Django admin still works. You can also set any other places that you do want to use Django templates there.
Groups an arbitrary number of variables into a list. `{% group "foo", 2, "bar" as my_list %}`
By enabling this backend: AUTHENTICATION_BACKENDS = ( 'path.to.my.backends.CaseInsensitiveModelBackend', ) Your users will now be able to log in with their username, no matter whether the letters are upper- or lower-case.
**Example usage**: {% copyright_since 2008 %}, {% copyright_since 2009 %} **Output**: © 2008—2009, © 2009 Use this templatetag in your footer to achieve proper formatting of copyright notice.
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!
This allows you to create an alphabetical filter for a list of objects; e.g. `Browse by title: A-G H-N O-Z`. See [this entry](http://developer.yahoo.com/ypatterns/pattern.php?pattern=alphafilterlinks) in Yahoo's design pattern library for more info. NamePaginator works like Django's Paginator. You pass in a list of objects and how many you want per letter range ("page"). Then, it will dynamically generate the "pages" so that there are approximately `per_page` objects per page. By dynamically generating the letter ranges, you avoid having too many objects in some letter ranges and too few in some. If your list is heavy on one end of the letter range, there will be more pages for that range. It splits the pages on letter boundaries, so not all the pages will have exactly `per_page` objects. However, it will decide to overflow or underflow depending on which is closer to `per_page`. **NamePaginator Arguments**: `object_list`: A list, dictionary, QuerySet, or something similar. `on`: If you specified a QuerySet, this is the field it will paginate on. In the example below, we're paginating a list of Contact objects, but the `Contact.email` string is what will be used in filtering. `per_page`: How many items you want per page. **Examples:** >>> paginator = NamePaginator(Contacts.objects.all(), \ ... on="email", per_page=10) >>> paginator.num_pages 4 >>> paginator.pages [A, B-R, S-T, U-Z] >>> paginator.count 36 >>> page = paginator.page(2) >>> page 'B-R' >>> page.start_letter 'B' >>> page.end_letter 'R' >>> page.number 2 >>> page.count 8 In your view, you have something like: contact_list = Contacts.objects.all() paginator = NamePaginator(contact_list, \ on="first_name", per_page=25) try: page = int(request.GET.get('page', '1')) except ValueError: page = 1 try: page = paginator.page(page) except (InvalidPage): page = paginator.page(paginator.num_pages) return render_to_response('list.html', {"page": page}) In your template, have something like: {% for object in page.object_list %} ... {% endfor %} <div class="pagination"> Browse by title: {% for p in page.paginator.pages %} {% if p == page %} <span class="selected">{{ page }}</span> {% else %} <a href="?page={{ page.number }}"> {{ page }} </a> {% endif %} {% endfor %} </div> It currently only supports paginating on alphabets (not alphanumeric) and will throw an exception if any of the strings it is paginating on are blank. You can fix either of those shortcomings pretty easily, though.
Middleware for implementing "hours of operation" for a website. In use (as configured here) on http://ianab.com/.
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!
There are probably ways to improve the implementation, but this was something I came up with when I wanted to change the default size of all of my CharField admin fields. Now all I have to do in my ModelAdmin class is: form = get_admin_form(model) or subclass BaseAdminForm if I need extra validation or more widget customization for an individual admin form.
http://steven.bitsetters.com/articles/2009/03/09/testing-email-registration-flows-in-django/ Testing email registration flows is typically a pain. Most of the time I just want to sign up with a test user, get the email link and finish the flow. I also want to be able to automate the whole process without having to write some SMTP code to check some mail box for the email. The best way I’ve found to do this is just to write out your emails to some file instead of actually sending them via SMTP when your testing. Below is some code to do just that. I’ve also created a Django management script that will open the last email sent out from your application, find the first link in it and open it in your web browser. Quite handy for following email registration links without logging into your email and clicking on them manually.
** DEPRECATED**, use [django-reversetag @ github](http://github.com/ulope/django-reversetag/tree/master) instead. If you want to be able to use context variables as argument for the "url" template tag this is for you. Just put this code somwhere where it will be run early (like your app's _ _init_ _.py) and of you go. Usage: {% url name_of_view_or_variable arg1 arg2 %} **NOTE:** This may possibly break your site! Every view name that is passed to url will be tried to be resolved as a context variable first! So if there is a variable coincidentally named like one of your views THEN IT WILL BREAK. So far it works great for me, but keep an eye out for name clashes.
A proper app was published for this: https://github.com/yourlabs/django-dynamic-fields Try it out !
Easy to use range filter. Just in case you have to use a "clean" for loop in the template. Inspired by [Template range tag](http://www.djangosnippets.org/snippets/779/) Copy the file to your templatetags and load them. [Django doc | Custom template tags and filters](http://docs.djangoproject.com/en/dev/howto/custom-template-tags/)
A simple template tag that generates a random UUID and stores it in a name context variable.
3110 snippets posted so far.