Serialize JSON object into a model object and retrieve a python dictionary on load
Based on [JSONField](http://djangosnippets.org/snippets/377/) Fork me on [github](https://gist.github.com/667930)!
- model
- json
Snippet List
My approach on class based views
By using __new__ the result of a class instantiation is not an object but the result of a method call. This way classes can be used for views the same way as functions.
- class based views
QLeftOuterJoins
This hack replaces all INNER JOINs inside to the LEFT OUTER JOINs (see http://code.djangoproject.com/ticket/3592 for explanation). Use: QLeftOuterJoins(Q(...) | Q(...) & (Q(...) | ....)).
- q
- query
- join
- left
- outer
Convert CamelCase to lowercase_with_underscores
Just a simple regex function to convert a camel case string ("ClassName") to a lower case string with underscores ("class_name"). Came across a need for this when I was trying to add properties to a model at runtime using `object.__class__.__name__`. This is a modification of the function "get_verbose_name" found in django.db.models.options.
- utilities
- formatting
- one-liners
Type checking templatetag filters
It's often useful to be able to check the type of an object in templates. Most recently I used this to do some trickery in my forms for certain field types. These template filters allow you to match the type of an object or a field widget with a string. It returns True if it matches and False if it doesn't or there is an error. for example: {% if form|obj_type:'mycustomform' %} <form class="custom" action=""> {% else %} <form action=""> {% endif %} {% if field|field_type:'checkboxinput' %} <label class="cb_label">{{ field }} {{ field.label }}</label> {% else %} <label for="id_{{ field.name }}">{{ field.label }}</label> {{ field }} {% endif %}
- templatetags
ModelMixin
Enables convenient adding of fields, methods and properties to Django models. Instead of: User.add_to_class('foo', models.CharField(...) User.add_to_class('bar', models.IntegerField(...) you can write: class UserMixin(ModelMixin): model = User foo = models.CharField(...) bar = models.IntegerField(...)
- mixin
- metaclass
- util
- metaprogramming
UUIDField oriented django User
This code monkey-patches the default User model to rather use a primary key of UUIDField (see http://www.djangosnippets.org/snippets/1496/). This code also makes the email field required. This code is wildly dangerous, not completely future proof, and probably not advisable to use. If you do wish to use it, it will be easiest to implement on a fresh db with a syncdb. If you need to migrate existing user data the onus is on you to figure out an appropriate db migration plan. I placed this code in a models.py, but it is probably more reliably placed in urls.py
- user
- auth
- uuid
- monkeypatch
Credit Card With Newforms
Alternative version of newform code for handling credit cards. Unlike the other two credit-card snippets (http://www.djangosnippets.org/snippets/764/ and http://www.djangosnippets.org/snippets/830/), this uses two drop-down boxes instead of text fields for the expiration date, which is a bit friendlier. It doesn't do as much checking as snippet #764 since we rely on the payment gateway for doing that. We only accept Mastercard, Visa, and American Express, so the validation code checks for that.
- newforms
- datefield
- credit-card
- expiration-date
send_file and send_data
Simple functions for downloading files - send_data sends the data directly, send_file as attachment. May need optimizing for large files.
- files
- download
DRY Fieldsets
I've devised a DRY method of declaring django fieldsets: ** Example usage: ** 1. Include the attached code in `fieldsets.py` 2. `models.py`: from django.db import models from fieldsets import Fieldset, ModelWithFieldsets class Person(ModelWithFieldsets): #instead of models.Model # this field will be placed in nameless fieldset example_field = models.IntegerField() # this fieldset will be grouped into one row Fieldset(grouped=True) first_name = models.CharField(max_length=64) surname = models.CharField(max_length=64) Fieldset("Contact Details", classes=('collapse',)) mobile_phone = models.CharField(max_length=10) email_address = models.EmailField() Fieldset("Address") street_address = models.CharField(max_length=255) # the next two fields will be grouped into one row of this fieldset Fieldset.new_group(2) suburb = models.CharField(max_length=64) state = models.CharField(max_length=64) 3. `admin.py`: from django.contrib import admin from models import Person from fieldsets import Fieldset class PersonAdmin(admin.ModelAdmin): fieldsets = Fieldset.get_fieldsets(Person) admin.site.register(Person, PersonAdmin) This example produces the equivalent of manually typing: fieldsets = ( (None, {'fields': ('example_field')}), (None, {'fields': (('first_name', 'surname'),)}), ('Contact Details', { 'fields': ('mobile_phone', 'email_address'), 'classes': ('collapse',)}), ('Address', {'fields': ('street_address', ('suburb', 'state'))}) ) But now if you want to rearrange your fields, rename, delete, insert, etc, you won't need to remember to update the fieldsets in the ModelAdmin. This implementation is a bit of a hack, but I believe a cleaner equivalent should be implemented in django itself.
- admin
- dry
- fieldsets
Better Static Image Serving With Fallback
Serves images from a local directory, but if it doesn't find it locally, then go look for it on a server. This is useful for sites with very large amounts of static content. Instead of copying all your prod images to dev every time you update the database, simply use this in your URL patterns to serve the images: `(r'^(?P<path>.*)$', 'static_fallback.serve', {'document_root' : '/path/to/my/files/'})` By default, it caches the images locally in the path it was supposed to find them. The fallback server URL can be specified in urls.py or settings as FALLBACK_STATIC_URL. Thanks to Johnny Dobbins for the idea. Based on the Nginx pass through image proxy concept. For more info [http://menendez.com/blog/using-django-as-pass-through-image-proxy/](http://menendez.com/blog/using-django-as-pass-through-image-proxy/)
- image
- static
- images
- fallback
Load a local settings file for dev/test environments
Add the snippet to your settings.py. If you have a settings_local.py it will load that one. Can be used in development environments where you might have different settings for your dev sandbox. You should exclude settings_local.py from SVN. By Rudy and Ed Menendez
- settings
- environment
- production
Custom model field to store dict object in database
**Disclaimer** This is proof of concept snippet, It can not be considered as best practice. Seems like it's better to store (key => value) in sepetare model with 'key' and 'value' fields. **Example** You can assign any dict to model field that can be dumped/serialized with Django json encoder/decoder. Data is saved as TextField in database, empty dict is saved as empty text. Tested with Django 1.2beta. import DictionaryField class UserData(models.Model): user = models.ForeignKey(User) meta = DictionaryField(blank=True) There are similar snippets: [JSONField 1](http://www.djangosnippets.org/snippets/377/) or [JSONField 2](http://www.djangosnippets.org/snippets/1478/).
- models
- fields
- json
Modify requests in your unit tests (improvement on RequestFactory)
This is an update to Simon Willison's snippet http://djangosnippets.org/snippets/963/, along with one of the comments in that snippet. This class lets you create a Request object that's gone through all the middleware. Suitable for unit testing when you need to modify something on the request directly, or pass in a mock object. (note: see http://labix.org/mocker for details on how to mock requests for testing) Example on how to use: from django.test import TestCase from yourapp import your_view from yourutils import RequestFactory class YourTestClass(TestCase): def setUp(self): pass def tearDown(self): pass # Create your own request, which you can modify, instead of using self.client. def test_your_view(self): # Create your request object rf = RequestFactory() request = rf.get('/your-url-here/') # ... modify the request to your liking ... response = your_view(request) self.assertEqual(response.status_code, 200) Suggestions/improvements are welcome. :)
- testing
- request
- client
- testcase
Functional Filters
I've been working on a project where I realized that I wanted to call methods on Python objects *with arguments* from within a Django template. As a silly example, let's say your application maintains users and "permissions" that have been granted to them. Say that permissions are open-ended, and new ones are getting defined on a regular basis. Your `User` class has a `check_permission(p)` method that return `True` if the user has been granted the permission `p`. You want to present all the users in a table, with one row per user. You want to each permission to be presented as a column in the table. A checkmark will appear in cells where a user has been granted a particular permission. Normally, in order to achieve this, you'd need to cons up some sort of list-of-dicts structure in Python and pass that as a context argument. Ugh! Here's how you'd use the `method`, `with`, and `call` filters to invoke the `check_permission` method from within your template. (Assume that you've provided `users` and `permissions` as context variables, with a list of user and permission objects, respectively.) <table> <tr> <th></th> {% for p in permissions %} <th>{{ p.name }}</th> {% endfor %} </tr> {% for u in users %} <tr> <td>{{ u.name }}</td> {% for p in permissions %} <td> {% if user|method:"check_permission"|with:p|call" %}X{% endif %} </td> {% endfor %} </tr> {% endfor %} </table> The `call_with` method is a shortcut for single-argument invocation; for example, we could have re-written the above as {% if user|method:"check_permission"|call_with:p %}...{% endif %} Anyway, this has been useful for me. Hope it's helpful for others! --chris P.S., tip o' the cap to Terry Weissman for helping me polish the rough edges!
- filter
- filters
- function
- object
- method