If you have a production, staging, testing and development environment, you might want to have a global checked in (in your version control system) settings.py for production + a local settings.py to override various settings (like database connection). It's also good for development, since developers don't - by incident - commit to the production settings.py, since they can use their local settings, that should be ignored (.cvsignore, .svnignore or similar).
A simple way to log in and log out users. It's most likely nowhere near as good as the built-in login forms. This was more of a learning experience for me. Nevertheless, the script works. Usage: def some_view(request): check_login(request) Some explanation can be found here: http://bit.ly/ete0
This patch allows to open a popup to edit the selected object of either the left or right select input of a filter_horizontal or filter_vertical field, when pressing the "Insert" key. Being a noob with general client-side issue, it's served as a patch that suits my needs. Maybe it's possible to do it cleaner by overloading the javascript methods, or get rid of the jquery dependency in order to integrate it into django trunk ... Any contribution is welcome! It's licensed under WTFPL license. Requires jquery.
Simple jquery creditcalculator
this avoids checking if POST contains data for forms. see source for usage example
Derived from [847](http://www.djangosnippets.org/snippets/847/) but allows for checks against multiple groups...
Usage: {% mailto email [linktext] %} `email' parameter is required; linktext is optional, defaulting to the email address.
A decorator for Django apps running Google AppEngine that requires a user to be authenticated.
One of the things about Django that has always irked me is that there seems to be no standard facility for just loading a page and displaying it, simply. Yes, there is the flatpages module, but it is primarily designed for loading content from a DB. While you specify a custom template and put in junk values for the DB content, it just feels like extra, unnecessary work. Thinking about the problem some more, I borrowed from the idea of flatpages and implemented a view that will load an otherwise unmapped template off the filesystem and render it. This is very useful when converting an existing site over. Just copy your files over. No need to map anything in the URL conf or use the admin to add any flatpage entries. Since it'll render the template, too, you can even use tags and what not, so it need not be a static page.
In your site’s settings.py module (in your site root), TEMPLATE_DIRS takes absolute paths. Here is a way to dynamically determine the absolute path to the application directory so you only have to specify relative paths within settings.py. Obviously, replace “application_directory” with the name of your application’s directory.
Reset lost django password without the use of sql.
To let the development server use the network you must use the ip of your machine.
With this, you can group form fields very easily. Since it does not create any html, you can use it not only to create fieldsets (with tables, lists, etc).
A simple addition for the urls.py that exposes the 404/500 templates during development. This way you can test how those look. They're mounted under /404/ and /505/ respectively. Add this at the bottom of your main urls.py.
Usage: @login_required def action_delete(request,object_id): return delete_view(request,object_id,ActionItem)