A quick django-pagination template fix to make it work with Bootstrap CSS Library 2.0. Usage: Install django-pagination and save the snippet in templates/pagination/pagination.html then {% paginate %} will work fine. See [Django-paginaation on Bootstrap CSS](http://ronbeltran.blogspot.com/2012/05/django-pagination-bootstrap-css.html)
This is something we're using over at Curse to keep things clean and simple for our users. * We needed a url for any language code (which the domain provides) vs a cookie * We needed a to only store 2 letter codes in the db for each language (thus the key doesn't always match the code) This consists of two major modifications: * LANGUAGES in settings.py is a completely different format and would need changed based on your setup * the locale middleware has a couple absolute instances of where to point a user by default.
This tag gives you an iterable Python [Calendar object](http://docs.python.org/library/calendar.html) in your template namespace. It is used in the [django-calendar](http://github.com/dokterbob/django-agenda) project. Use it as follows in your template: {% get_calendar for <month_number_or_variable> <year_or_variable> as calendar %} <table> <tr> <th>Mon</th> <th>Tue</th> <th>Wed</th> <th>Thu</th> <th>Fri</th> <th>Sat</th> <th>Sun</th> </tr> {% for week in calendar %} <tr> {% for day in week %} <td>{{ day.day }}</td> {% endfor %} </tr> {% endfor %} </table>
Creates a filter for displaying calendars. Passed value is a dict of dicts of arrays: that is, indexed by year, then by month. The list of month days is used to generate links in the format specified by the argument. If a particular day is *not* in the list, then no link will be generated and it will just display a number for that day. **EXAMPLE** `{{ calendar|calendar_table:"/schedules/calendar/[Y]-[m]-[d]/" }}`
**Number format:** number/year **Purpose:** When the user adds a new bill, the "number" field will be automatically filled with the appropriate number. * The snippet automatically increments the bill number based in the highest number available. This is because in the use case, the user could start by *any* number, and we couldn't use the PK number (p.e. if the user first object number is 324/10, using the PK will convert it to 1/10) **NOTE:** bill_type is a Boolean value to mark if the bill is outgoing or ingoing. Since we only need to mark the outgoing ones, we filter through this field.
There's a whole range of examples online for resizing images in Django some of which are incredibly comprehensive with a wide variety of options. Here's my take on the task that serves as a simple drop in for when you don't want to include a separate app. - Only generates the resized image when first requested. - Handles maintaining proportions when specifying only a width or a height. - Makes use of PIL.ImageOps.fit for cropping without reinventing the wheel.
Middleware that checks if you ran all South migrations. If not, it will throw an exception. Make sure to only use this middleware in development!
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 }} );
There are cases when rendering had already started, but you have to return Your response nevertheless. A good example is when you have a django-cms plugin and a form in it. You want to redirect after the form was processed, but normally you can't do it. More information here: https://github.com/divio/django-cms/issues/79 http://groups.google.com/group/django-cms/browse_thread/thread/79ab6080c80bbcb5?pli=1
This is caching mechanism augmented to help address a number of common pitfalls in caching: cache stampeding, simultaneous expiry, cache invalidation, and the storing of None as a legitimate value. No doubt the automatic key generation could stand to be simplified, but it works.
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.
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.
Difference from standard Django 1.4 implementation is just structure of list. In django `<input>` elements are *wrapped* by their labels, and look like this:: <ul> <li><label><input/> Label 1</label> <li><label><input/> Label 2</label> </ul> This widget puts labels *after* input elements:: <ul class="form-button-radio"> <li><input/> <label>Label 1</label> <li><input/> <label>Label 2</label> </ul> It makes possible to define style for both inputs and labels, hiding inputs and making labels look like pressable buttons. No javascript needed, just CSS (see docstring). To auto-submit the form when pressing a button, JQuery can be added:: <script> $(document).ready(function() { $('ul.form-button-radio input[type="radio"]').change(function() { $(this).parents('form').submit(); }); }); </script>
Optio's [soaplib](http://trac.optio.webfactional.com/wiki/soaplib) makes it really straightforward to write SOAP web service views by using a decorator to specify types. Plus it's the only Python library, as of today, which is able to generate WSDL documents for your web service. You can test it with a soaplib client: >>> from soaplib.client import make_service_client >>> from foo.views import HelloWorldService >>> client = make_service_client('http://localhost:8000/hello_world/', HelloWorldService()) >>> client.say_hello('John', 2) ['Hello, John', 'Hello, John'] And get an WSDL document: >>> client.server.wsdl('') '<?xml version=\'1.0\' encoding=\'utf-8\' ?><definitions name="HelloWorldService" ... </definitions>'
Snippet to convert django model into soaplib model and expose it by SOAP This snippet use [DjangoSoapApp sniplet](http://www.djangosnippets.org/snippets/979/) to autogenerate WSDL.