This middleware will add a log of the SQL queries executed at the top of every page, in the form of an IE-like 'infobar'. It also includes a query count and total and per-query execution times.
This snippet is based on snippet #344 "SQL Log Middleware + duplicates" by guettli.
I did some adjustments to the code, to also add support for the application/xhtml+xml mime type, aswell as add the code for the infobar.
Need DEBUG on, aswell as DEBUG_SQL, should not be used on production sites.
It also expects a 16x16 png image called infobar_icon.png, which it is looking for in the /media/images folder (or /static/images, depending on your MEDIA_URL setting). I used a little light bulb icon from the Tango icon set, but am unable to attach the image. Any 16x16 png will do off course.
Update 0.1.1: In the initial version of this middleware, the path to /media/images was hard-coded, and you had to adjust this middleware accordingly. Now, it correctly uses the MEDIA_URL setting from your settings.py file, so you no longer have to edit this middleware.
0.1.2: Made some adjustments to the CSS to get rid of a padding bug when the bar was displayed on a Django error page. Also if a page contains no queries, it won't bother printing an 'empty' table, with just column headers.
0.1.3: More tweaks to the CSS, odd/even row shading on queries table.
0.1.4: More CSS tweaks again
0.1.5: Minor tweaks
0.1.6: Sorry, I just realised that after some time, this snippet broke in the latest SVN of Django with a Unicode error, as arthur78 mentioned.
I have managed to fix it, by wrapping line 258 and 259 in an str() function.
This is a little improvement to the [idea](http://www.djangosnippets.org/snippets/540/) from sheats a few days ago.
I like it over the previous solutions because it doesn't involve doing anything other than running `./manage.py shell` inside your project directory. You don't have to create any files anywhere or remember to call anything, and `ipython` still works fine outside of a Django project.
Throw this code in `~/.ipython/ipy_user_conf.py` (`ipythonrc` has apparently been deprecated).
the trick resides in `field.field.required`. The intuitive way of testing this in the templates is to access `field.required`. But it's not the good one. Enjoy!
[Found via Django users Google Groups](http://groups.google.com/group/django-users/browse_thread/thread/ce83f74fb1156b4b/0df36947de16a071?lnk=gst&q=required+field#0df36947de16a071)
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.
This is a simple Logging Middleware that uses the python logging functions.
Simply drop this snippet in a file in your project such as `logmw.py` (don't try to call it `logging.py` though), then add the class to MIDDLEWARE_CLASSES in your settings file. (for instance, `'mysite.logmw.LoggingMiddleware'`)
Updated 8/25/08: added PhonyLogger class that swallows log messages when logging is disabled, so code doesn't have to care if it's on or not (thanks to goodness for suggesting the idea, though I missed it before)
Some time you want to add some common fields to a group of models, for example, in a **Generalization/Specialization** relationship. One could have a base model as the generalization class and specialized models with a foreign key to that base model with an unique attribute but I don't like it that way so, I just do this code to add some commons attributes to a lot of models.
If you have many models that all share the same fields, this might be an option. The fields are added directly to each model, e.g. while they will be duplicated on the database level, you only have to define them once in your **python** code.
This code is a cleaner way(I think!!!) to do it and will do the same that [this one](http://www.djangosnippets.org/snippets/317/). I hope this piece of code will be useful for you.
Simple template tag that allows you to inspect an object in the context for debugging. It will inspect django models and forms using introspection. Dicts and lists are formatted to truncate long data. Pretty much everything else just displays the __str__ representation + class name.
Example output: http://dsanity.net/introspectiontag.html
Usage:
put tag code as file introspection.py in your templatetags directory. Place the html template in your template path under "inspect_object.html".
Then in your template:
{% load introspection %}
{% inspect_object obj "test object" %}
The first parameter is the object to inspect, the second is the name used for display purposes.
Django ImageBundle tag, an implementation of image bundle by google: http://code.google.com/p/google-web-toolkit/wiki/ImageBundleDesign. Here is how to use it: http://www.djangosnippets.org/snippets/278/
This is something we're using over at Curse to keep things clean and simple for our users.
* We needed a url for any language code (which the domain provides) vs a cookie
* We needed a to only store 2 letter codes in the db for each language (thus the key doesn't always match the code)
This consists of two major modifications:
* LANGUAGES in settings.py is a completely different format and would need changed based on your setup
* the locale middleware has a couple absolute instances of where to point a user by default.
A handy ANSI-colored logging mechanism to display the SQL queries and times in the terminal when using django-admin.py runserver. DEBUG mode must be true for this to work.
Simple contact form, using a javascript form checker which you can use any you want to you can just modify the form in the way you want to.
The form checker I use I include in the 'base.html' page before the </head> section end. You can use it freely. http://media.xorl.de/form.js . A lot of this code is comprised of other peoples forms that didn't suit the simple purpose of a *really* basic contact form which I wanted, so I rebuilt it up from bits and pieces to make a simple basic form.
This is a django filter which will create an html mailto link when you use the syntax:
{{ "[email protected]"|encode_mailto:"Name" }}
Results in:
<a href="mailto:[email protected]">Name</a>
Except everything is encoded as html digits.
The encoding is a string of html hex and decimal entities generated randomly.
If you simply want a string encoding use:
{{ "name"|encode_string }}
This was inspired by John Gruber's [Markdown](http://daringfireball.net/projects/markdown/syntax#autolink) project
Useful for when you want to use an instance's values as the initial values of a form which you didn't use `form_for_instance` to create.
Handles foreign keys and many-to-many fields just fine.
You're looking at the most-bookmarked snippets on the site; if you'd like to help useful snippets show up here, sign up for an account and you'll get your own bookmarks list.