This code will work on any model using correct address data in its fields that also require latitude and longitude data to be updated on saving.
It uses pythons own default urllib and json, so no need to install 3rd party stuff to make it work.
This method is preferred to getting it on the fly, due to the OVER_QUERY_LIMIT that you will get when parsing many address, this way means it stays up to day in the model and will update when any part of the address changes.
Simplified version of the snippet that renders model to PDF [http://djangosnippets.org/snippets/2540/](http://djangosnippets.org/snippets/2540/)
This PDF view mixin for Django Class Based Views.
See working project example: https://github.com/elena/django-pdfmixin-example
---
This is based on the case scenario where you have a model which has a `DetailView`.
You then construct a bespoke PDF for the same model that is unrelated in any way to the `DetailView`.
The PDF needs to be returned as a `HTTPResponse` object. The model object is provided.
Sometimes we may need to generate a *ModelChoiceField* in which choices are generated at runtime, depending on the locale language. The snippet generates a *ChoiceField* based on a queryset and a specific attribute of the Model, ordering the choices by the attribute content in the locale language.
**Usage example** (inside a form declaration)
country = LazyModelChoiceField(sort_by='name', queryset = \
Country.objects.all, empty_label=_('All countries'), label=_('Country'))
Based on lsbardel LazyChoiceField implementation (snippet 1767)
Helper functions to use the Google Visualization API in Django. Module stores queries to use and creates a JSon representation of a Google Visualization DataTable for each by inspecting the query's model. Looks up any choices defined for the columns.
Depends on Google Visualization Python API:
https://code.google.com/p/google-visualization-python/
To use, define the queries to use with the Visualization API at the head of views.py with:
add_query(queryset, 'query name')
then in view functions, get the JSon representation of a Google Visualization DataTable for the query with:
my_json = get_viz_json('query name')
Within the HTML template, pipe the JSon through safe:
var dataTable = new google.visualization.DataTable( {{ my_json|safe }} );
This is a simple logging [filter](https://docs.djangoproject.com/en/1.5/topics/logging/#topic-logging-parts-filters) to ensure that user-entered passwords aren't recorded in the log or emailed to admins as part of the request data if an error occurs during registration/login.
This is a modification of http://djangosnippets.org/snippets/1707/ that handles the database going down or PG Bouncer killing the connection. This also works in things like Twisted to make sure the connection is alive before doing a real query. Thanks @mike_tk for the original post!
EDIT: Updated the wrapper to handle multi-db. Before it was using the first connection it made, now it creates an attribute name for the connection based on the name of the database.
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.