This function wraps boilerplate code to get the current page in a view, obtaining the page number from some URL query string variable, e.g., ?page=2 The interface is inspired by the interface of Paginator. The implementation follows an example given in Django documentation.
Suppose you have two models A and B. The models have lots of large text/json fields and other heavy data. Your view is showing some list of `B.select_related(A)`, however, it is using just few lightweight fields. You want to defer all heavyweight fields in order to offload your DB and limit its traffic, but it is a tedious error prone work, that smells a bit with over-optimization. Real example, you have Product and Category objects. Both have large description fields with lots of text data. However, these fields are only needed on product detail page or on category detail page. In other cases (eg. side menu, some product suggestion block etc) you just need few lightweight things. Solution: add `LightweightMixin` to your models manager and specify your `heavyweight_fields` and `always_related_models`. # all visible products with necessary relations prefetched and heavyweight # fields deferred. qs = Product.objects.lightweight() # custom queryset with default defers applied. description and ingredients fields will # be normally deferred, but in this case they are explicitly selected qs = Product.objects.filter(my_filter="that", makes="sense") qs = Product.objects.as_lightweight(qs, select=('description', 'ingredients')) The best way to work with this snippet is to add the mixin to all managers in order to use `lightweight()` and `public()` calls. The `as_public()` is intended for your visibility, `select_related()` and `batch_select()` queryset settings. When you need full blown object, use `public()` queryset. When you need a lightweight list of objects, use `lightweight()` queryset. When your application is completed, check the database querylog for frequent unnecessary large and ugly queries. Group all queries that were made by `lightweight()` querysets, make a list of unnecessary heavy fields and add them to manager's `heavyweight_fields`. If your `as_public()` uses `select_related()` joining heavy objects, then you can also specify `always_related_models` to defer some fields of these relations too. Why? Because database IO will become your major bottleneck someday, just because you fetch 2Mb of data in order to render some tiny menu. With proper caching this is not a major issue, but proper queries may be sign of proper coding.
This is a management command to export an app to csv files, or import from csv files. Code originally from django-csvimport
This snippet allows to create user in django auth system without logging in. After this user logs in via Facebook account social user is created and bound to existing user.
A template filter to make proper nouns posessive. If `context_var` was 'skarphace': {{ context_var|s }} Would be: skarphace's
Modelform cant inhertit from forms. To solve this issue, split thing you wanto to inherit into filed definition and functionality definition. For modelform use the base_fields.update method as mentioned in the code.
This is another fork of http://djangosnippets.org/snippets/2729/ that fixes the issue. Unlike those other versions i give you instructions so it works for you, this is modified a little. Instructions: If you want to import the passwords from drupal you need to prepend to each of them the word drupal so it looks like this: drupal$S$DQjyXl0F7gupCqleCuraCkQJTzC3qAourXB7LvpOHKx0YAfihiPC Then add this snippet to someapp/hashers/DrupalPasswordHasher.py And then in your settings add this: PASSWORD_HASHERS = ( 'django.contrib.auth.hashers.PBKDF2PasswordHasher', 'someapp.hashers.DrupalPasswordHasher', 'django.contrib.auth.hashers.PBKDF2SHA1PasswordHasher', 'django.contrib.auth.hashers.BCryptPasswordHasher', 'django.contrib.auth.hashers.SHA1PasswordHasher', 'django.contrib.auth.hashers.MD5PasswordHasher', 'django.contrib.auth.hashers.CryptPasswordHasher', ) So, what did i modify First i added the attribute algorithm to the class, django uses this word to identify wich hasher to use, so the passwords beggining with drupal should be verified with the hasher.algorithm == 'drupal' Ok so know django knows to use our class, but now our passwords won't validate because we changed them by adding the word drupal, so what do we do? we modify the verify method to remove the word drupal before verification :P Hope it helps
Theses two templatetags make easy to add an active class on a navigation link. The first one is based on a regexp an search if the request path match it. The second one simply use view names.
Use this directive to show google-map if you don't want to use 'raw' directive. default location is my favorite place. Of course you can change it :)
This is a YAML version of http://djangosnippets.org/snipptes/2397
Provide additional context_data in case the submitted form is valid. This can be a message to confirm that the changes are saved.
Usage: `{%formfield form.description rows="3"%}`
Message Exception
Email Validation Snippet.
The version of [snippet](http://djangosnippets.org/snippets/2397/) that works with Django 1.5. Kudos to [kmike](http://djangosnippets.org/users/kmike/) for the original snippet.
2955 snippets posted so far.