based on #2020
This one is even more generic than the previous generic ones since you can specify in fields any attribute you will give to the admin interface and not just fields from the model.
You can for example directly export the list_display as a list of fields, including look-ups for related attributes that you may have defined in a function inside the Admin Class
A simple example to show how to manage an history of memo-on-save.
Each time the user saves the model, he must provide a memo message.
The full memos history is shown as a read-only tabular-inline.
For each memo, user and date are also registered
([Django-Admin-Collapsed-Inlines](https://github.com/virajkanwade/Django-Admin-Collapsed-Inlines) could be usefull)
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 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.
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.
You're looking at the top-rated snippets currently on the site; if you'd like to contribute, sign up for an account and you'll be able to rate any snippet you see.