This was a wild experiment, which appears to work!
One model holds all the data, from every object version ever to exist. The other model simply points to the latest object from its gigantic brother. All fields can be accessed transparently from the little model version, so the user need not know what is going on. Coincidently, Django model inheritance does exactly the same thing, so to keep things insanely simple, that's what we'll use:
class EmployeeHistory(FullHistory):
name = models.CharField(max_length=100)
class Employee(EmployeeHistory):
pass
That's it! Django admin can be used to administer the `Employee` and every version will be kept as its own `EmployeeHistory` object, these can of course all be browsed using the admin :-)
This is early days and just a proof of concept. I'd like to see how far I can go with this, handling `ForeignKey`s, `ManyToManyField`s, using custom managers and so on. It should all be straightforward, especially as the primary keys should be pretty static in the history objects...
*updated 3 August 2009 for Django 1.1 and working date_updated fields*
This is a context processor that will allow you to cycle the values of your MEDIA_URL context variable. It will cycle through the urls defined in settings.MEDIA_URLS, so that you can distribute your media url's between multiple servers.
Django 1.0 is apparently hard-coded for cascading deletes. I find that I often have nullable foreign keys on models whose records must not be deleted along with those they refer to. I override Model.delete() in an intermediate base class and execute this method to clear out all nullable foreign keys before allowing a delete to proceed.
This is the complete image_processor.py module, allowing you to add an image containing an arbitrary piece of text. I use this to label the horizontal axis of a skills-matrix report.
Credit www.renewtek.com for paying me to do this stuff!
As a quick, simple way to take a list of items make a table with n items per row I added a custom template filter for modulo of an integer.
To make the custom filter first create a "templatetags" directory in your application folder then add an empty file called "__init__.py" in that new directory. Finally add a file "myapp_tags.py" with the above code in it.
In the template you load your custom filter with {% load pictures_tags %} and then you can make a table with n elements per row using a simple for loop and in if statement.
This works because if ( for_loop.counter modulo n ) is zero ("if not" evaluates to True on zero values), then it makes a new table row. You might note that if the number of items in list is a multiple of n, there will be an empty row at the end... preventing that adds needless complexity so I left that out!
Often I want fields in my models to be unique - Django's `unique` works too late in model form validation and will throw an exception unless you check for it by hand. This is a bit of code that cleans up the boiler plate of checking if different fields are unique.
Set `exclude_initial` to `False` if you want to raise an error if the unique field cannot be set to whatever value the instance had before.
**Update**
Thanks fnl for rightly pointing out that Django's `unique=True` does check for this - just make sure to pass `instance=obj` when you're initializing your forms. _HOWEVER_ a problem you'll typically run into with this is though you want a field to unique, you also want multiple entries to be able to be `blank`. This can help you!
This is a bastardisation of a few of the Amazon s3 file uploader scripts that are around on the web. It's using Boto, but it's pretty easy to use the Amazon supplied S3 library they have for download at [their site](http://developer.amazonwebservices.com/connect/entry.jspa?externalID=134).
It's mostly based on [this](http://www.holovaty.com/blog/archive/2006/04/07/0927) and [this](http://www.davidcramer.net/code/112/writing-a-build-bot.html).
It's fairly limited in what it does (i didn't bother os.walking the directory structure), but I use it to quickly upload updated css or javascript. I'm sure it's a mess code wise, but it does the job.
This will first YUI compress the files, and then gzip them before uploading to s3. Hopefully someone might find this useful. It will also retain the path structure of the files in your MEDIA_ROOT directory.
To use it, set up your Amazon details, download the [YUI Compressor](http://developer.yahoo.com/yui/compressor/), and then enter the folder you wish to upload to s3, and basically run the script - python /path/to/s3_uploader.py
Subclass `Resource` to create a view that will dispatch based on the HTTP method of the request.
class View(Request):
def DELETE(self, request):
...
def GET(self, request):
...
def PUT(self, request):
...
Other snippets provided inspiration:
* [436](http://www.djangosnippets.org/snippets/436/)
* [437](http://www.djangosnippets.org/snippets/437/)
* [1071](http://www.djangosnippets.org/snippets/1071/)
* [1072](http://www.djangosnippets.org/snippets/1072/)
The code is also available on [GitHub](http://github.com/jpwatts/django-restviews/).
Originally posted by [Leah Culver on her blog](http://leahculver.com/2008/11/25/couchdb-documents-python-objects/).
This allows you to convert a CouchDB document into a python object and work on CouchDB fields as if they were properties of a python object.
Add extra form elements in your contib admin
Install
add this in header of base.html
<script type="text/javascript" src="/static/jquery-1.2.6.min.js"></script>
http://code.google.com/p/jqueryjs/downloads/detail?name=jquery-1.2.6.min.js
This snippet is a piece of middleware that can be used to allow an administrator to create a flatpage that will override an existing URL.
Why would you want such a thing? Maybe an admin needs to be able to override individual detail pages of an item list at will and doesn't want to be bothered mucking around with urlconf and restarting apache2.
Obviously, it's not the ideal situation for permanent overrides (in that case, you'd be better off writing an exception in the urlconf), but it's good for the temporary, one-off, situations that may arise for whatever reasons.
Wraps specified URL patterns with login_required decorator. Allows you to quickly require login for an area of your site based only on a URL pattern.
Similar to [zbyte64's snippet](http://www.djangosnippets.org/snippets/966/)
Wraps specified URL patterns with permission_required decorator. Allows you to quickly require a specific permission for an area of your site based only on a URL pattern.
Assumes a passing knowledge of how Django permissions work and how to use them. See [User authentication in Django](http://docs.djangoproject.com/en/dev/topics/auth/#permissions) for more information.