Generic admin action to export data into excel/csv
This is a generic admin action to select and export the data from admin view including the proxy models.
- export csv
- django admin export
- genric data export
- export excel
This is a generic admin action to select and export the data from admin view including the proxy models.
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.
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
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.
[code] {% get_video_urls url as url_object %} or get object attribute: {% get_video_urls obj "url" as url_object %} {{ url_object }} original url {{ url_object.video_id }} original url or video_id {{ url_object.resource }} youtube, vimeo, None {{ url_object.iframe_url }} original url or iframe_url {{ url_object.js_api_url }} original url or js_api_url [/code]
This is my POC code for a progress bar backend (for delivering JSON to some AJAX frontend) in Django using Django-Celery (with RabbitMQ). It is quite concise, yet it took me a while to get there because Celery's Documentation is IMHO rather puristic. Web development is meant to be copy-paste! Here you go!
Allows you to include content from flatpages in class-based views. You can specify the url for the flatpage you want, or let it be determined by request.path.
For use with S3 BotoStorage STATICFILES_STORAGE ="storages.backends.s3boto.S3BotoStorage" and AWS_PRELOAD_METADATA = True Custom management command that compares the MD5 sum and etag from S3 and if the two are the same skips file copy. This makes running collect static MUCH faster if you are using git as a source control system which updates timestamps.
You have pagination for some blog. At the bottom of the page you have space for seven page links. This module tries to always fill out those slots. It handles the corner cases for first page and last page etc. The logic for this is complex and sadly the Django pagination module does not deal with this. Also, it's a hell to implement this in Django templates. Believe me. See pydoc for detailed documentation. Running tests was done with `doctest`.
Usage: {% load helper_tags %} {% get_available_languages as languages %} {% for lang_code, lang_name in languages %} <link rel="alternate" hreflang="{{ lang_code }}" href="{% change_lang lang_code %}"> {% endfor %}
This decorator will memoize the results of instance methods, similar to `django.util.functional.memoize`, but automatically creates a cache attached to the object (and therefore shares the life span of the object) rather than requiring you to provide your own. Note this is intended for instance methods only, though it may work in some cases with functions and class methods with at least one argument. This is useful for memozing results of model methods for the life of a request. For example: class MyModel(models.Model): #Fields here @auto_memoize def some_calculation(self): #some calculation here return result
Based on [#2712](../2712/) "This snippet creates a simple generic export to csv action that you can specify the fields you want exported and the labels used in the header row for each field. It expands on #2020 by using list comprehensions instead of sets so that you also control the order of the fields as well." The additions here allow you to span foreign keys in the list of field names, and you can also reference callables.
I thought it would be useful to have a `get_addr()` method available on request objects, similar to the `get_host()` provided by Django. This middleware will add a `get_addr()` method to requests which uses the `X-Forwarded-For` header (useful if you're behind a proxy) if it's present and you have the `USE_X_FORWARDED_FOR` header set to `True` (default is `False`) and otherwise will use the `REMOTE_ADDR` environment variable. Note that if you are *not* behind a proxy and have `USE_X_FORWARDED_FOR` set to `True`, then clients can spoof their IP by simply setting the `X-Forwarded-For header`.