This is an improvement on other ButtonAdmin implementations.
A few features : It allows you to specify whether button appears on change form or change list; whether the form is to be saved before the resulting function is called; whether the button should be displayed
Look at the bottom of the snippet for usage.
And make sure you admin urls are enabled using (r'^admin/', include(admin.site.urls)) instead of the old method
Passing datetimes from Python to a [YUI DataTable](http://developer.yahoo.com/yui/datatable/) via JSON served by [django-piston](http://bitbucket.org/jespern/django-piston/) turned out to be surprisingly rocky. This code actually works with ``YAHOO.lang.JSON.stringToDate`` (*not* ``YAHOO.util.DataSource.parseDate``) which cannot handle time zone specifiers other than "Z" or dates without timezones.
The YUI [DataSource](http://developer.yahoo.com/yui/datasource/) which uses this looks something like this - note that simply setting ``format:"date"`` does not work as that uses ``YAHOO.util.DataSource.parseDate``, which uses``Date.parse`` to do the actual conversion, which will involve browser-specific formats and as of this writing only Chrome's native ``Date`` can reliably parse ISO 8601 dates.
myDataSource.responseSchema = {
resultsList: '…',
fields: [
…
{
key: 'my_date_field',
parser: YAHOO.lang.JSON.stringToDate
},
],
…
};
Perhaps you don't want to drop a table, but you also want to do something faster than Model.objects.all().delete() but without resorting to raw SQL. This function, clear_tables, will call the sql_flush operation on a list of tables.
simple_tag is nice, but it would be useful if it had a "as variable" clause at the end. This little bit of code factors out the reusable parts and makes a tag almost as simple as simple_tag. Now you can create tags like the following:
{% some_function 1 2 as variable %}
{% some_function db person %}
To add a new function, just do:
register.tag("new_function",
make_tag(new_function))
(I think you have to take the quotes off a string.)
Most other methods I've seen for splitting an app's models across multiple files involve adding a couple lines to every model. This method factors out those duplicate lines into one place.
This snippet is for resolve the Django-PyAMF unicode problems, through the django force_unicode function called recursively, with a tuple of different charsets.
With this snippet, I made a set of admin actions for assigning `Quality` objects to `Package` objects.
The Django docs for [ModelAdmin.get_actions][1] explain the dictionary of tuples that is returned.
[1]: http://docs.djangoproject.com/en/1.1/ref/contrib/admin/actions/#django.contrib.admin.ModelAdmin.get_actions
Sometimes, we need to pass hidden fields with an initial value in forms but cannot trust the returned values because it could have been tampered.
So here is a form that adds an additional 'hidden' field (called 'form_hash') that hashes all the initial value of hidden fields and checks for tampering.
Pretty straightforward to use.
This is the same as [django.forms.extras.widgets.SelectDateWidget](http://code.djangoproject.com/browser/django/trunk/django/forms/extras/widgets.py#L16) but changing the order of the rendered select boxes to: day, month, year.
Okay - so I came across a really annoying problem earlier, where I wasn't able to *easily* load a formwizard as a segment into an existing view, and wrap it using my existing site template layouts. This was *REALLY* annoying. Especially since I wanted to keep as much of a 'overall' templating and application logic in the views.py (and just leave the forms.py to handle the form and its own templating for the form pages)
I spent about 2 hours trying to make this as conventional as possible, and finally came up with a solution. The result is something which looks as similar to the usual functionality. This also meant that there is seperation between form styling and overall site styling, so your forms can be used between multiple sites, and if your overall site template uses extends, then the context support keeps this nicely in order.
This also allows you to initialise the formwizard in a nicer way.. Of course, in each file, you'll need to import the necessary bits (like importing the testform from the view etc)
Decorator that stores the `request.path` URL in a session variable to be used later, e.g. in a "Continue Shopping" link on a cart page. Wrap and view that you want to be able to link back to easily. When those views are called, it updates the session with the current `request.path` value. This can be pulled back out of the session whenever you need to provide a link back from whence the user came.
This custom model field is a variant of NullBooleanField, that stores only True and None (NULL) values. False is stored as NULL.
It's usefull for special purposes like unique/unique_together.
One small problem is here, that False is not lookuped as None.
This snippets is a response to [1830](http://www.djangosnippets.org/snippets/1830/)
**NOTE: I now have a better implementation of this (nicer api, less signal wrangling) available [on PyPI here](https://pypi.python.org/pypi/django-exclusivebooleanfield)**
Sometimes you want to be able to make one (and only one) row in your model 'featured' or 'the default one'
If you have some kind of parent model you could have a ForeignKey on the parent to hold that info, but that won't always be the case - eg you may have no parent, or multiple parent models.
With the exclusive_boolean_fields() helper you can do it with or without a parent model and it possibly makes the admin interface a bit simpler.
Allows the whole widget to be required but still have optional fields in it.
For instance we have a NameField, which takes a firstname and lastname and optionally a middlename.
With this we can just have 1 widget.
Middleware class logging request time to stderr.
This class can be used to measure time of request processing within Django. It can be also used to log time spent in middleware and in view itself, by putting middleware multiple times in INSTALLED_MIDDLEWARE.
Static method `log_message' may be used independently of the middleware itself, outside of it, and even when middleware is not listed in INSTALLED_MIDDLEWARE.