You can switch boolean fields in the admin without editing objects Usage: ` class News(models.Model): # ... pub = models.BooleanField(_('publication'),default=True) # ... pub_switch = boolean_switch(pub) class Admin: list_display = ('id', 'pub_switch') ` Thanks for [svetlyak](http://www.djangosnippets.org/snippets/398/).
**Javascript merging and compression templatetag** One of the most important things for improving web performance is to reduce the number of HTTP requests. This is a templatetag that merges several javascript files (compressing its code) into only one javascript. It checks if this merged file is up to date, comparing modification time with the other javascripts to merge. Usage: {% load jsmerge %} {% jsmerge mergedfile js/file1.js js/file2.js js/file3.js %} The previous code will: 1. Search in `settings.MEDIA_ROOT` for all files passed by parameter. 2. Create a `/path/to/media_root/mergedfile.js` (if it doesn't exist or it's not up to date). This file is a merging plus compression of all javascripts. 3. Return this HTML fragment: `<script type="text/javascript" src="/media_url/mergedfile.js"></script>`
A URL field specifically for images, which can validate details about the filesize, dimensions and format of an image at a given URL, without having to read the entire image into memory. Requires [Python Imaging Library](http://www.pythonware.com/library/pil/). *4th October, 2008* - updated for 1.0 compatibility.
A couple of useful template filters for splitting a list (or QuerySet) up into rows or columns.
The first function (ftype_batch) is a view that passes the first part of the CSV filename and a queryset intended to write out to the file. run_batch prepares the HttpResponse for incrementally writing, and write_batch actually writes out the data. The logic in write_batch is custom to what I need done, but as long as the csv writer receives a sequence to write, it should work.
Simple drop-down date field for use. You can specify date range by initiating new DateDropdownWidget. Welcome comments!
Usually, you can add links in the admin using such code: class Pingback(models.Model): #... target_uri = models.URLField( _('Target URI')) #... def admin_target(self): return '<a href="%(targ)s">%(targ)s</a>' % {'targ': self.target_uri} admin_target.short_description = _('Target URI') admin_target.allow_tags = True #... class Admin: list_display = ('id', 'admin_target') But when you have two or more url fields, such approach becomes to expensive. Follow the DRY principe and use my code in such way: # Just add this line instead of the ugly four lines **def blabla** admin_target = link('target_uri', _('Target URI'))
I would like to catch the raw plaintext password if a user created or change his password. First i tried to handle this with signals.post_save at the User class, like this: `dispatcher.connect(update, signal=signals.post_save, sender=User)` The problem is, in the User model exists e.g. 'last_login'. So the save method called every time, the user logged in :( And with post_save i get only the hashed password and not the plaintext source password. I found a simple way to trigger a user password change. I hacked directly into the django.contrib.auth.models.User.set_password() method. See the sourcecode. There exists a discussion in the [django-users thread](http://groups.google.com/group/django-users/browse_thread/thread/7c074e80a9cdcd21/) about this.
The rationale behind this decorator is described in django-users google group. Usage: === urls.py === urlpatterns = patterns('', (r'^', include('apps.app1.views')), (r'^app2', include('apps.app2.views')), ) === apps/app1/views/__init__.py === @url(r'^index/$') def index(request): ... @url(r'^news/$') def news(request): ... urlpatterns += include_urlpatterns(r'^members', 'apps.app1.views.members') === apps/app1/views/members.py === @url(r'^profile/$) def profile(request): .... @url(r'^secure/$) def secure(request): ... @url(r'^path1/$', '^path2/$') # you can specify several patterns def multipath_view(request): ... def helper(): # easily distinguishable - no @url! ... Summarizing, the benefits are: * no more creating and supporting urlpattern maps (less files, less code, more DRY) * have the url associated with a view in-place * easily see if a function is a view * fully compatible with other chained decorators
Generate a list of page links like: First Prev 1 2 3 *4* 5 6 7 Next Last To use: 1. Put Paginator.py into your app directory 2. Copy pagination.html to your templates directory 3. pass a paginator object to your Context 4. include the pagination.html template on the page you wanted paginated Feel free to send ideas for improvement. If enough people ask, I'll package this as a single app and perhaps even make the template inclusion into a templatetag for even easier use.
I use this filter quite a bit to keep my templates less cluttered. Instead of: {%if some_variable%}, {{some_variable}}{%endif%} I can write: {{some_variable|format:", %s"}} A common one I use is: {{some_variable|format:"<p>%s</p>"}}
This snippet allows you to use YUI's autocomplete widget in a easy way. 1. Download YUI (http://developer.yahoo.com/yui/) library and put it into MEDIA folder (in my case I put YUI/build/ directory as base/yui/ in my MEDIA folder) 2. Create lookup view for your autocomplete field. See 'test_ajax_ac' function to see how this lookup view may be built. You have to define JsonResponse somewhere in your files. JsonResponse is taken from: http://www.djangosnippets.org/snippets/154/ 3. Define url for newly created view in urls.py (in usual way) 4. Include necessary .js and .css files in your page (see example in test_ajax.html) 5. Assign widget to a field - see form's __init__ at UserForm in the example. Additional (optional) parameters are: format_result_fname (name of javascript function for formatting results - see YUI docs for examples)), item_select_handler_fname (name of javascript function for handling item select event (see YUI docs)). When using YUI take care about proper skin - you'll possibly need to define wrapper like: `<div class="yui-skin-sam">....</div>` around your html code.
This widget uses: [DHTML Calendar Widget](http://www.dynarch.com/projects/calendar/). It is very simple implementation but may be easily extended/changed/refined. 1. Necessary files: First download calendar package and extract it to your MEDIA folder (MEDIA/calendar/...) You'll also need a small gif that will be shown as a button that allows user to display calendar. By default this 'gif' is searched at '[MEDIA]images/calbutton.gif' but you may change this path in the code (calbtn variable). You need to download or create callbutton.gif image by yourself (it is not included). 2. Include css and js files in your page (as shown in the comment in the code). 3. In form code assign a widget to a field as usual (see newforms documentation for more details). 4. It is possible to change date format by specifying different value for 'dformat' attribute of widget class. If you get javascript errors while trying to open calendar try to use english translation file (calendar-en.js). I've found that some translations, eg. Polish, are broken by default. In this case you should override your language translation with english one and translate it by yourself (it is easy).
This tag builds on top of the [ifusergroup tag](http://www.djangosnippets.org/snippets/282/), fixes a small bug and introduces support for else blocks.
This snippet uses signals to replace the `contrib.auth.models.User.set_password()` function with one that uses *crypt* instead of *sha1* to hash the password. *Crypt* is of course cryptographically inferior to *sha1*, but this may be useful for interoperability with legacy systems e.g. when sharing a user authentication database with unix, a MTA etc. For some reason the `User` class doesn't emit a `class_prepared` signal, which would otherwise be a better choice here. That's why I had to resort to patching each `User` instance separately. A clean way to deploy this snippet is to place it in the `models.py` of an otherwise empty app, and add the app in `settings.INSTALLED_APPS`. The order of `INSTALLED_APPS` doesn't matter since we're patching instances, not classes.