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.
Converts a passed decorator to one that can be applied to a class based view (ie. automatically decorates dispatch). This means no more overriding dispatch for every view / request method you want to apply decorators to. Works in Django 1.3 but I suspect it probably works in 1.2 as well.
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.
2955 snippets posted so far.