Date-based generic views do not provide pagination by default but Django is very extensible. It provides a Paginator that takes care of pagination. Since date based views usually order by descending order ie from latest entry to the oldest, I used a queryset to order the items (on a field called 'date_pub') and then pass this queryset to the paginator which takes care of the pagination.
A Django image thumbnail filter, adapted from code by [Batiste Bieler](http://batiste.dosimple.ch/blog/2007-05-13-1/). This updated version drops support for cropping and just rescales. You should use it in your templates like this: `<img src='{{ MEDIA_URL }}{{ image.get_image_filename|thumbnail:"300w,listingimages" }}' alt="{{ image.title }}" title="{{ image.title }}" />` This will produce a 300-pixel wide thumbnail of image, with the height scaled appropriately to keep the same image aspect ratio. 'listingimages' is the path under your MEDIA_ROOT that the image lives in - it'll be whatever upload_to is set to in your ImageField. If instead you wanted an image scaled to a maximum height of 140px, you'd use something like this: `<img src='{{ MEDIA_URL }}{{ image.get_image_filename|thumbnail:"140h,listingimages" }}' alt="{{ image.title }}" title="{{ image.title }}" />` Note the number has changed from 300 to 140, and the trailing letter from 'w' to 'h'. Please leave feedback and bug reports on [my blog, Stereoplex](http://www.stereoplex.com/two-voices/a-django-image-thumbnail-filter). I've only lightly tested this so you'll probably find something!
this decorator will render template and encode it as JSON string if it find **ajax_request** variable in GET. It will not parse parent (extended) templates, only given template and nested (included). Only blocks will be rendered and encoded to JSON naming block__*BLOCKNAME*. Simple javascript can do ajax request adding *?ajax_request* or *&ajax_request* (if needed) and update given html elements if they id's are same as block__*BLOCKNAME*. you can find a full code (including javascript) at my (http://projects.barbuza.info/trac/browser/django_addons/django_ajax/trunk/ sandbox).
I thought it would be a neat idea to use the PyCrust shell for interacting with my models, instead of using the plain old shell. So what I did, is take a copy of the file: django/core/management/commands/shell.py Altered it, and saved it as: django/core/management/commands/pycrust.py For this to work, you should have pycrust installed (python-wxtools in ubuntu) and save this snippet as django/core/management/commands/pycrust.py, then run as follows: ./manage.py pycrust instead of ./manage.py shell Have fun!
This Middleware is to log users out after a certain amount of time has passed. You'll want to add AUTO_LOGOUT_DELAY to your settings.py, set to a number of minutes after which a user should be logged out. It adds the key 'last_touch' to the session, you'll want to change that if you happen to be using that already.
decorator which performs basic http auth authentication against the known userbase. This decorator is only for xml-rpc services. When there is no basic auth a proper response will be returned
Extended extends tag that supports passing parameters, which will be made available in the context of the extended template (and all the way up the hierarchy). It wraps around the orginal extends tag, to avoid code duplication, and to not miss out on possible future django enhancements. Note: The current implementation will override variables passed from your view, too, so be careful. Some of the argument parsing code is based on: http://www.djangosnippets.org/snippets/11/ Examples: {% xextends "some.html" %} {% xextends "some.html" with title="title1" %} {% xextends "some.html" with title="title2"|capfirst %}
This Update adds requested support for self referential fields. This is useful if you need to compute and store potentially hundreds or thousands of objects and relationships quickly. To perform the inserts it will hit the database 1 plus N/100 times per affected table and where N is the number of rows to be inserted. It will use INSERT or LOAD DATA INFILE on MySQL. Run this on your test database first and make sure all of your field defaults and null values are set appropriately as you could attempt to insert a NULL where it isn't allowed and end up with a partial insert. This code is reasonably well tested and has been used for database pre-loading and operations on live sites. My test suite, however, is focused on my own use cases. Any input, i.e. failures, for creating more tests would be appreciated. Lots of Details in the Doc String. Currently only MySQL, however there is some crude skeleton code to support other databases.
This is an example how to use relative paths in settings file, but still keep settings readable.
**Usuage:** {{ comment.comment|truncatechars:20 }} **Why to use:** First of all, my english isn´t the best. I hope you will understand my text anyways :) Ok, I had a problem with some "kiddies" posting huge comments like "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaahhhhhhhhhhhhhhhhhhh this game rooooooooooocks!!!!!!!!!!!!!!!!". Django has no function to "kill" that huge words within a string. So I´ve coded this little peace and hope that someone could use it. Greets from Germany, Aveal http://www.onlinewars.eu
I like the per-site caching offered by Django (it's simple) and I like the cache to be dependent on the chosen language. Unfortunately with the current `CacheMiddleware` you can either have the one or the other but not both at the same time. `VaryOnLangCacheMiddleware` is a small wrapper around `CacheMiddleware`. It looks at the `request.LANGUAGE_CODE` (set by `LocaleMiddleware`) and appends it to your `CACHE_MIDDLEWARE_KEY_PREFIX`. So "mysiteprefix" becomes "mysiteprefix_en" or "mysiteprefix_de-AT" depending on the user's chosen language. Site-wide, so no messing with per-view decorators and stuff. To use this, make sure `VaryOnLangCacheMiddleware` comes below `LocaleMiddleware` in your settings.py. If you haven't set your `CACHE_MIDDLEWARE_KEY_PREFIX`, it's works, too. **Update:** Replaced `super()` calls with `CacheMiddleware.xxx(self, ...)`.
Somebody mentioned in #django the other day that they have multiple databases with the same schema... Well *lucky me* so do I!! This is one way to work with this issue. I've also included migrate_table_structure just in case the schema doesn't exist in the new database yet. As per the multiple-db-support branch, write all of your databases into the OTHER_DATABASES in settings.py. You can now copy models from your various models.py files and use them in different databases at the same time. This can also be used to migrate databases from one dialect to the other without having to translate your data into an interim format (e.g. csv, XML). You can just do: qs = MyModel.objects.filter(**filters) NewModel = duplicate_model_and_rels(MyModel, 'new_db') #Assuming that the schema is already in new_db: for mod in qs: new = NewModel() new.__dict__ = mod.__dict__ new.save() I tried this using some hacks with SQLAlchemy, and the above approach is a huge amount quicker! I've used this to copy some stuff from an oracle db, into a sqlite db so i could carry on working later and transferred about 20,000 in 5 mins or so. GOTCHAS ======== This only works against my copy of multi-db as I've made a couple of changes. My copy is substantially the same as my patch attached to ticket 4747 though, so it might work to a point (especially the data migration aspect). If it doesn't work hit me up and I'll send you my patch against trunk. I'm not too crazy about the code in copy_field, it works fine, but looks ugly... If anyone knows of a better way to achieve the same, please let me know.
link and img are both HTML construction helpers. Good idea to use these helpers if your html don't fit into templates.
Simple template tag that assumes some common conventions in order to quickly get a link to a specific model instance.
This script will reload apache when any modifications are detected in a folder - useful only if the development server or mod_python's reload does not suit your needs for testing. It requires Linux 2.6.13+, Python 2.5, and the [development version of pyinotify](http://seb.dbzteam.com/pages/pyinotify-dev.html).