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.
Usually I start an authentication app with this model. Don't forget to set it up in the settings file AUTH_PROFILE_MODULE = 'authentication.UserProfile'
TaskViewMixin can be mixed in with a Class Based view and handles the scheduling and polling of a task. During task execution, a waiting page is rendered that should refresh itself. Once the task is complete, the view may then render a success page and can collect the payload of the task for rendering the result.
You just use standart django query terms, for example: <form> <input class="field_text filter_from" type="text" name="cost__gte" placeholder="from" value="{% if request.GET.cost__gte %}{{ request.GET.cost__gte }}{% endif %}"> <input class="field_text filter_to" type="text" name="cost__lte" placeholder="to" value="{% if request.GET.cost__lte %}{{ request.GET.cost__lte }}{% endif %}"> </form> model: class Object(models.Model): cost = models.IntergerField() objects = ObjectManager()
This script generates an GraphViz graph of your database structure from your django apps list.
Dumps DB data for each application to that application's fixtures directory. For example: $ ./manage.py dump_app_data ... $ hg status M apps/foo/fixtures/dev.json M apps/bar/fixtures/dev.json
This lets you load global fixtures from a directory you set as `FIXTURES_ROOT` in your settings.py. For example, setting `FIXTURES_ROOT` to `/path/to/myproject/fixtures/` I tend to like to keep fixtures that should be loaded when a new instance of a site is deployed, but not auto-loaded (so they won't rewrite any data that comes after), in a project-level fixtures directory like this. Sometimes these fixtures can be useful in your test suites, so this is a convenient way to load them. Usage: `load_global_fixtures('sites.json', 'contacts.json')` `load_global_fixtures('sites.json', 'contacts.json', fixtures_root='/some/other/path', verbosity=1)`
Apply the `login_required` decorator to all the handlers in a class-based view that delegate to `cls.dispatch`. Optional arguments: * redirect_field_name = `REDIRECT_FIELD_NAME` * login_url = `None` See the documentation for the [`login_required`](https://docs.djangoproject.com/en/dev/topics/auth/#the-login-required-decorator) method for more information about the keyword arguments. Usage: @LoginRequired class MyListView (ListView): ...
By using map_path([directory_name]) you can avoid hard coding paths for a specific OS in your settings.py
See code
See the function docstring.
A simple model and admin entry for managing Cache table through the Django admin interface.
To put obfuscated primary keys in any class, simply inherit from this one. For example: class Offer(ObfuscatedPKModel) You can match for these bigint primary keys in your urls.py like this: '^offer/(?P<offer_pk>[0-9\-]+)$'
Sometimes you need to store information that the server needs in unencrypted form (e.g. OAuth keys and secrets), but you don't really want to leave it lying around in the open on your server. This snippet lets you split that information into two parts: * a securing passphrase, stored in the Django settings file (or at least made available via that namespace) * the actual secret information, stored in the ORM database Obviously, this isn't as secure as using a full blown key management system, but it's still a significant step up from storing the OAuth keys directly in the settings file or the database. Note also that these fields will be displayed unencrypted in the admin view unless you add something like the following to ``admin.py``: from django.contrib import admin from django import forms from myapp.fields import EncryptedCharField class MyAppAdmin(admin.ModelAdmin): formfield_overrides = { EncryptedCharField: {'widget': forms.PasswordInput(render_value=False)}, } admin.site.register(PulpServer, PulpServerAdmin) If Django ever acquires a proper binary data type in the default ORM then the base64 encoding part could be skipped. This snippet is designed to be compatible with the use of the South database migration tool *without* exposing the passphrase used to encrypt the fields in the migration scripts. (A migration tool like South also allows you to handle the process of *changing* the passphrase, by writing a data migration script that decrypts the data with the old passphrase then writes it back using the new one). Any tips on getting rid of the current ugly prefix hack that handles the difference between deserialising unencrypted strings and decrypting the values stored in the database would be appreciated! Sources of inspiration: [AES encryption with M2Crypto](http://passingcuriosity.com/2009/aes-encryption-in-python-with-m2crypto/) [EncryptedField snippet](http://djangosnippets.org/snippets/1095/) (helped me improve several Django-specific details)
3110 snippets posted so far.