A generic base class for extending ModelAdmin views. This can be used likewise: def myview(self, request, object_id): obj = self._getobj(request, object_id) < do something > def get_urls(self): urls = super(MyAdmin, self).get_urls() my_urls = patterns('', url(r'^(.+)/myview/$', self._wrap(self.myview), name=self._view_name('myview')), ) return my_urls + urls
This snipped removes a specific fields from the fieldsets. This is very useful to leave a field 'out' in the admin, likewise: def get_fieldsets(self, request, obj=None): fieldsets = super(BlaModelAdmin, self).get_fieldsets(request, obj) if not request.user.has_perm('change_blah'): remove_from_fieldsets(fieldsets, ('blah',))
This is a hack to get HTML 5 to work for Firefox 2. It Sends the xhtml content-type to all Gecko based browsers where version is less than 1.9, or "rv:1.9pre" or "rv:1.9a" or "rv:1.9bx" where x is less than 5. I created this hack based on the information I found on this site, http://html5doctor.com/how-to-get-html5-working-in-ie-and-firefox-2/. Just put this code in one of your middleware files (i.e. mysite/middleware.py) and then add it in your MIDDLEWARE_CLASSES in your settings.py. Example: MIDDLEWARE_CLASSES = ( ... 'mysite.middleware.HTML5Firefox2Hack', ... )
This is a custom template tag that clears the cache that was created with the **cache** tag. {% load clearcache %} {% clearcache [fragment_name] [var1] [var2] .. %} Create **app/templatetags** folder with **__init__.py** and copy code into **clearcache.py** file. polls/ templatetags/ __init__.py clearcache.py Based on django.templatetags.cache. See Django docs on [custom template tags](http://docs.djangoproject.com/en/dev/howto/custom-template-tags/)
`GPXMapping` is a subclass of `LayerMapping` that imports GPX files into 3D GeoDjango models (requires Django 1.2 or SVN r11742 and higher). Here's an example of GeoDjango models for GPX points and tracks, respectively: from django.contrib.gis.db import models class GPXPoint(models.Model): timestamp = models.DateTimeField() point = models.PointField(dim=3) objects = models.GeoManager() def __unicode__(self): return unicode(self.timestamp) class GPXTrack(models.Model): track = models.MultiLineStringField(dim=3) objects = models.GeoManager() Assuming the above models, then `GPXMapping` may be used to load GPX tracks and waypoints (including elevation Z values): track_point_mapping = {'timestamp' : 'time', 'point' : 'POINT', } track_mapping = {'track' : 'MULTILINESTRING'} gpx_file = '/path/to/file.gpx' lm = GPXMapping(GPXPoint, gpx_file, track_point_mapping, layer='track_points') lm.save(verbose=True) lm = GPXMapping(GPXTrack, gpx_file, track_mapping, layer='tracks') lm.save(verbose=True)
Calls a view by request.method value. To use this dispatcher write your urls.py like this: urlpatterns = pattern('', url(r'^foo/$', dispatch(head=callable1, get=callable2, delete=callable3)), ) If `request.method` is equal to head, `callable1` will be called as your usual view function; if it is `get`, `callable2` will be called; et cetera. If the method specified in request.method is not one handled by `dispatch(..)`, `HttpResponseNotAllowed` is returned.
There are times when you want to hook into the Variable class of django.template to get extra debugging, or even to change its behavior. The code shown is working code that does just that. You can monkeypatch template variable resolution by calling patch_resolver(). I recommend using it for automated tests at first. My particular version of _resolve_lookup does two things--it provides some simple tracing, and it also simplifies variable resolution. In particular, I do not allow index lookups on lists, since we never use that feature in our codebase, and I do not silently catch so many exceptions as the original version, since we want to err on the side of failure for tests. (If you want to do monkeypatching in production, you obviously want to be confident in your tests and have good error catching.) As far as tracing is concerned, right now I am doing very basic "print" statements, but once you have these hooks in place, you can do more exotic things like warn when the same object is being dereferenced too many times, or even build up a graph of object interrelationships. (I leave that as an exercise to the reader.) If you want to see what the core _resolve_lookup method looks like, you can find it in django/templates/__init__.py in your installation, or also here (scroll down to line 701 or so): [source](http://code.djangoproject.com/browser/django/trunk/django/template/__init__.py)
Have you always been annoyed by how you set up this elaborate big database schema and weren't able to have **ON DELETE CASCADE ON UPDATE CASCADE** in dbshell? This solves the problem; create the two files and and empty *__init__.py* and put them somewhere in your path. Then say DATABASE_ENGINE='postgresql_psycopg2_cascade' in settings. Really I'd like this to be in the ForeignKey object, were it upstream Django or an own version of it, but it doesn't seem possible. Ideas on how to make this configurable are more than welcome! Props go out to Ari Flinkman for the inspiration to do this!
We often need to use a Profile form and we want to be able to modify the first_name, last_name and sometimes the email address. Here is how I do it. In this case I want to check the email so I did a specific form for it. But it is quite easy to add it.
The counter initializes the variable to 0, and next it increments one by one: {% load counter_tag %} {% for pet in pets %} {% if pet.is_cat %} {% counter cats %} {% else %} {% counter dogs %} {% endif %} {% endfor %} # cats: {{cats}} # dogs: {{dogs}}
Substitute hyphens with spaces to enale URLs to reference to multi-word tags
This is a basic view for exporting data from models. It is designed so that you can provide the GET variables used for searching/filtering within listdisplay pages in the admin, and the code will filter the same way. It allows ouputting of model data in various formats using serializers. This should be used as a urlpattern through get_url, so that you can use the admin_view decorator to properly secure the data.
This is a basic model view for exporting data from models. It is designed so that you can provide the GET variables used for searching/filtering within listdisplay pages in the admin, and the code will filter the same way. It allows the output of model data in various formats using serializers or templates.
This is a really simple snippet , but is not documented well ... Whit this , you can limit the output of one field in 25 characters before you test that is equal or over 30 characters! Note that the snippet cut the text and add three points at the end (...) Enjoy!
I don't understand why the cache is accumulated between the tests. I thought one of the axioms of unit testing is that the tests should not affect each other. Couldn't find anything that explains why it's done this way but it seems a bit strange. Anybody know if there's a reason or is this a reason for me to upload a patch to Django code?
3109 snippets posted so far.