The WorldIP database provides real-world geographical location. Database is more correct than [Whois records and Whois-based databases](http://www.wipmania.com/en/blog/why-worldip-data-rather-than-whois-data-examples/), that show geographic locations of network owners, and not the geographic location of Internet-connected PC or appliance itself.
See more: [WIPmania.com](http://www.wipmania.com)
Binds $Model to $ModelAdmin without having to specify each binding manually. The ModelAdmins **must** have the same name as the model (as well as same case) with Admin appended.
Example:
from django.db import models
class SomeModel(models.Model):
name = models.CharField(max_length=255)
class AnotherModel(models.Model):
name = models.CharField(max_length=255)
# bind administration
bind_administration('myproject.myapp.models', 'myproject.myapp.admin')
The @cache_holding decorator works in a per-function base, you can specify a list of models or just a model and the second argument is the time in seconds to be cached. You can modify the proxy class by a keyword argument so you can do cache to all kind of things, also if you want to use a prefix as key + the hash value you can specify the prefix keyword argument.
This code will allow you to use chained select boxes in the django automatic admin area. For example, you may have a product, then a category and subcategory. You'd like to create a product, and then choose a category, and then have a chained select box be filled with the appropriate subcategories.
This should work as a `django.views.generic.list_detail` generic view but will produce PDF version of given template.
This code is merged code from perenzo's [example](http://www.djangosnippets.org/snippets/659/) and code from `django.views.generic.list_detail` module.
`pisa` package is required from (http://www.htmltopdf.org/download.html) with `html5lib` package and Reportlab Toolkit 2.1+
NOTE: this is code for Django 0.96. In Django 1.0 change in line 3: ObjectPaginator to Paginator
Works much like an inclusion_tag but allows the template_name to be given as an argument or defaults to partials/MODELNAME.html where MODELNAME is 'got' from the context object you want to render. Its very rough so improvements very welcome!
It would be nice to be able to pass new context variables as template tag [keyword] arguments for use in the template to be rendered so you basically have a template tag equivalent for render_to_string...
Example usage in a template:
{% render_partial post %} or {% render_partial post partials/super_post.html %}
I recently got a form working via jQuery and Django. This was not easy for me to do and I thought I'd record my finding here.
The form submits via jQuery and the "form" plugin. Please visit jQuery's home page to find all those links.
This code handles:
* urls.py -- passing both normal and 'Ajax' urls to a view.
* views.py -- Handling both kinds of requests so that both normal and ajax submits will work.
* The HTML template with the script for submitting and some bling.
Error handling
===
I like to stay DRY so the idea of checking the form for errors in javascript *and* checking it in Django irks me. I decided to leave that up to Django, so the form submits and gets validated on the server. The error messages are sent back to the browser and then displayed.
Changing the size of max_length in the model is fast. But sometimes you forget to
update all running systems which use this model.
This unittest helps you to find the difference between Model and DB before the users get uncaught exceptions.
A script that gathers statistics of translated, untranslated and fuzzy literals of translations (be it Django itself or a project using Django).
For that it re-scans the tree and generates a up-to-date POT in a temporary location, so the statistics of translation "coverage" are calculated relative to the current status of the tree. It doesn't touch the tree it is analyzing at all.
It should be run from the directory containing the `locale/` directory of your project or from the `django/` directory of a Django copy.
It is based on the `makemessages` Django management command (or rather its previous standalone `make-messages.py` script incarnation) and uses the same command line switches:
* `-d <domain>` -- `<domain>` is `django` or `djangojs`. Optional, defaults to `django`.
* `-l <language>` OR
* `-a` -- process all languages
Decorator for views that checks that the user is staff, redirecting
to the log-in page if necessary.
A wrapper for user_passes_test decorator based on login_required
Possible usage:
@is_staff
def view....
urlpatterns = patterns('',
(r'^databrowse/(.*)', is_staff(databrowse.site.root)),
)
Another one like [980](http://www.djangosnippets.org/snippets/980/), but using re's instead.
I haven't benchmarked these, but my guess is that [981](http://www.djangosnippets.org/snippets/981/) is faster for strings of pure digits and this is faster for larger chunks of text that happen to contain digits. If you're generating the numbers yourself, I'd just use 981 on a number right when you generate it.
This is based on [980](http://www.djangosnippets.org/snippets/980/), removing the unnecessary use of StringIO. Hopefully the translation can be educational.
Arabic and Farsi languages use their own digits. This template filter translates any digits in the supplied unicode string into the correct ones for the language. The previous version used StringIO to parse the string one character at a time. It now uses regular expressions.
I just saw that kcarnold created two snippets that also removed the need for StringIO: [981](http://www.djangosnippets.org/snippets/981/) and [982](http://www.djangosnippets.org/snippets/982/). That last snippet is almost the same as this one.
You're looking at the top-rated snippets currently on the site; if you'd like to contribute, sign up for an account and you'll be able to rate any snippet you see.