create_c
Instead of creating a dictionary on every view everytime you could do this and just call it like c = create_c(request)
- templates
- request
- data
- csrf
Instead of creating a dictionary on every view everytime you could do this and just call it like c = create_c(request)
This registers a users taking data from a submitted form, sends a confirmation email, activates the account when the confirmation link is clicked and logs the user in
This is a function based on django's urlize modified to show different media based on their url. It supports images, links, mp3/ogg links, youtube videos, vimeo videos and dailymotion videos. I added a switch called mini to have two modes to show things in different places. When mini is activated it will only parse the first url provided and discard the rest as well as limiting the height.
For example: Last modified: {% localdt item.modified_utc %} ({% localtimesince time.modified_utc %}) Converts the input datetimes to the timezone specified by the localtz context variable (it can also be explicitly specified, and all those other sensible things). Input UTC datetimes can be specified using either a datetime or a timestamp. Provides `localdt`, `localtime`, `localdate` and `localtimesince`.
This is a modification of Django 1.3's transaction.commit_on_success() decorator and context manager. It's inspired by snippet [1343](http://djangosnippets.org/snippets/1343/) which unfortunately don't work in current Django neither as a context manager. In my junior projects it works fine but I've not tested in critical projects yet! YMMV ! How it works: it simply counts the nesting level and does the real transaction enter/exit only on first call and last call respectively (code copied from Django's commit_on_success() ). It use thread local storage to save the per-thread nesting level count safely. To use it just put the code in a file (i.e. nested_commit_on_success.py) and import and use it exacly as normal commit_on_success(), both as decorator (@nested_commit_success) or context manager (with nested_commit_on_success(): ). Any feedback is welcome!
Django lacks support of MySQL's "tinyint" 8-bit-integer datatype. This snippet gives you a TinyIntegerField and a PositiveTinyIntegerField. Falls back Django's SmallIntegerField if a different database-engine is used
This snippet allows you to return back to the filtered change_list after clicking "Save" on a change form. Other snippets I've found don't seem to take into account clicking on "Save and add another" or "Save and continue"
Django's built-in {% regroup %} template tag is great, but sometimes, you need to pass in the attribute you want to group on instead of declaring the attribute when you define the tag. {% dynamic_regroup %} is identical in function to {% regroup %}, except that it will attempt to resolve a context variable for the attribute you want to group by. {% dynamic regroup %} is also backward compatible, so you can also hand in the attribute literal and it will work as expected. See the end of the code for an example of usage.
I needed to display formset into table and I didn´t like solution I have found. So I have written this simple tag you can use it in templates like this: ` {% for row in formset|square_it:6 %} <tr> <td> </td> {% for form in row %} <td> {% for field in form %} {{ field }} {% endfor %} </td> {% endfor %} `
See code
Needed a function to check if any field in an instance has changed. If so update a datetime field to now to keep track of changes. This function is an override of the save function in the model.
Adding this mixing to your existing class based views allows for outputting of queries into any registered serialzier format -- very handy for dynamic JS based GUI on the JSON format. This generic view mixing was created on our last project which required a fancy JS based user experience and yet also needed to be accessible through non JS enabled browsers.
This is a portion of my code for creating a hierarchical relation between assemblies, subparts, and parts and so forth (although really, everything is a Part) The project being used is [django_dag](https://github.com/elpaso/django-dag) For the sake of example, let's use this structure: * Bike 1 * - Front Tire & Back Tire combo 000 * - - Front Tire 000 * - - Rear Tire 000 * - Frame 000 * - Gearset type 000 * - - Crank 000 * - - Rear Cassette 000 * . * Bike 2 * - Front Tire & Back Tire combo 001 * - - Front Tire 001 * - - Rear Tire 000 * - Frame 001 * - Gearset type 000 * - - Crank 000 * - - Rear Cassette 000 Using the above example, I couldn't use a MPTT structure because Gearset 000 is used in 2 different parents (bike 1 and bike 2). So I had to use the DAG [(wiki)](http://en.wikipedia.org/wiki/Directed_acyclic_graph) structure which allows multiple parents. The `Relationship` model holds the dag information, mainly a parent and child field. (Tire combo 001 is child of Bike2, front tire 001 is child of tire combo 001, etc) After get the dag structure using the `ancestors_tree` method on a Part object, I search for the BillOfMaterial info for that whole tree. In my case the Bill Of Material info is unique per assembly, so that's why there are seperate models. It becomes a bit of a pain to have to save/delete both the relationship and BoM models at the same time, and to check if one exists to create the other etc. But I've made my first 'hack' through it to have a function project, and am ready to make some revisions now.
This script generates an GraphViz graph of your database structure from your django apps list.
By using map_path([directory_name]) you can avoid hard coding paths for a specific OS in your settings.py
3110 snippets posted so far.