This is a XML-RPC server, that uses arguments in URLs and every dispatcher instance is prepared in memory during webserver run. It's good, for example, for securing XML-RPC server with hashed strings and there are a lot of similar use cases. Usage: from xmlrpclib import ServerProxy server = ServerProxy('http://example.com/xmlr-rpc/%s/' % something, allow_none=True) server.do_something(*args)
Custom ImageField filename
It's quite common to use Django's `static.serve` functionality to serve media assets via the built-in development server. However, I always find that this is far too noisy - every asset produces a line of output on the console, and any debug messages I want to put there are hard to see. This management command monkey-patches the built-in `runserver` command so that it only generates a line of output for actual Django views - anything else is served as usual, but is not logged to the console. In fact the original version was already doing this for admin media, but not for your own media - I've just extended the logic. Put this in the management/commands directory of an installed app, saving it as (for example) `runserver_quiet`, then just do `./manage.py runserver_quiet` to run - it will accept all the same arguments as the built-in version.
I often find myself testing that the queryset returned by a method contains the instances I expect. I use a custom method, **assertQuerysetEqual()**, to test the equality of two querysets or lists:: def test_some_values(self): qs = get_user_list() self.assertQuerysetEqual(qs, [normal_user, super_user]) Makes it easy to test small querysets against lists whose values are known and expected.
django-adminwidgetswap =============== adminwidgetswap is used for dynamically swapping out widgets from django's generated admin. This allows applications to be packaged generically without the need for WYSIWYG dependencies editors- giving the application consumer the freedom to chose admin widgets without modifying original app source. Author ====== [David Davis](http://www.davisd.com) (http://www.davisd.com) [dynamically change django admin widets at runtime (django-adminwidgetswap) blog post](http://www.davisd.com/blog/2010/04/17/dynamically-change-django-admin-widgets-at-runtime/) Usage =============== To change a widget in django's admin, just put adminwidgetswap.py on the python path, import adminwidgetswap.py and use: adminwidgetswap.swap_model_field(model, field, widget) ...to change a widget for a direct model admin's field --- adminwidgetswap.swap_model_inline_field(model, field, widget) ...to change widgets for inlines of a specific model and field --- adminwidgetswap.swap_model_and_inline_fields(model, field, widget) ...to change both the widget for the direct model admin's field as well as all inline usages for the model and field --- I usually have a project-level application called website, and I put this initialization code inside the website app's __init__.py Usage - parameters =============== model is the Model class (eg. models.GalleryImage) field is the field name you're looking to swap (eg. 'image') widget is the widget you're going to swap for (eg. widgetlibrary.ThumbnailWidget())
Inspired by this [terse blog post](http://www.ghastlyfop.com/blog/2008/12/strip-html-tags-from-string-python.html). This filter was designed to simplify the stripping out of all (x)html in a given template var, while preserving some meta information from anchor, and image tags. Why is this even useful? If you have pre-assembled portions of templates, or model fields containing html, that you want to use to populate a *search index* like [django-haystack](http://haystacksearch.org/) you can safely discard all the markup, while keeping the text that should be still searchable. Alt text, and title attributes are worth keeping!
Django loads tests found in models.py and tests.py (if present) or actually a module or package named 'tests' under the app. Since tests can be a package, one can create a 'tests' directory, split the test cases across multiple files under 'tests' and import them from tests/__init__.py with: # tests/__init__.py from test_mod1 import * from test_mod2 import * ... from test_modN import * For a small number of files that's not too bad but it gets old as more files are added, plus it is error prone (e.g. test cases shadowing others with the same name). The snippet above simplifies the test splitting without importing everything into the same namespace. Typical usage: # tests/__init__.py from ... import get_suite suite = lambda: get_suite(__name__)
This is a ModelChoiceField where the choices are rendered in optiongroups (this is already posible with a normal Choicefield) For this to work properly the queryset you supply should already be ordered the way you want (i.e. by the group_by_field first, then any sub-ordering) See [related blog article](http://anentropic.wordpress.com/2010/03/23/django-optiongroups-for-your-modelchoice-field/)
Based on #1381 Use this piece of code to add IPv4/IPv6 and network support to Django. An IPAddressField allows you to find IP's for a given subnet. An IPNetworkField allows you to find a subnet for a given IP or find a subnet within a subnet. For starters, simply paste it into a new file in your app called fields.py. IPAddressField example # models.py from fields import IPAddressField class IPTest(models.Model): ip = IPAddressField() To search for an IP within a given subnet from ipaddr import IPNetwork IPTest.objects.filter(ip__in=IPNetwork('10.0.0.0/24')) IPNetworkField example # models.py from fields import IPNetworkField, IPNetworkQuerySet class IPTest(models.Model): objects = IPNetworkQuerySet.as_manager() network = IPNetworkField() To search for a subnet with a given IP from ipaddr import IPAddress IPTest.objects.network('network', IPAddress('10.0.0.1'))
Field which accepts list of e-mail addresses separated by any character, except those which valid e-mail address can contain.
This is a piece of middleware that reports the logged-in user back to Apache. This should cause the logged-in user to be present in the apache access log. Put it in `settings.MIDDLEWARE_CLASSES` after `AuthenticationMiddleware`. This has been tested with mod_python but does [not work with wsgi](http://groups.google.com/group/modwsgi/browse_thread/thread/8785a99d4ba7ee99).
Template designers often require access to individual form fields or sets of form fields to control complex form layouts. While this is possible via looping through form fields in the template it can lead to ugly logic inside templates as well as losing the ability to use the as_* form rendering methods. This class when mixed into a form class provides hooks for template designers to access individual fields or sets of fields based on various criteria such as field name prefix or fields appearing before or after certain fields in the form, while still being able to use the as_* form rendering methods against these fields.
I never found a good snippet or tutorial to get the app_list (in django.admin) on other pages except the index page. So i started asking on irc j00bar has given me a very nice answer, but first i didn't know what to do with it till now. Anyways this snippet is very handy for the people who wants this but don't know how to get it. This is special made for the django version 1.1 Installation is quite easy, it is a context processor, so download this file put anywhere in your project, i got it in a app called cms_theme (theme and template related stuff.) and put the location in your settings.py file, example: `TEMPLATE_CONTEXT_PROCESSORS = ( 'django.core.context_processors.auth', 'django.core.context_processors.debug', 'django.core.context_processors.i18n', 'django.core.context_processors.media', 'django.core.context_processors.request', '****cms.cms_themes.context_processors.theme', '****cms.cms_themes.context_processors.applist', )` The '****' stuff is nothing, i replaced my company name with it. Of course you may put the context processor anywhere else, that is your choice. Good luck! Alexander
This is some (probably) pretty dodgy code that allows for foreign keys in the admin's list_filter without using a custom FilterSpec. It overrides the django.db.models.options.Options get_field class to handle spanned relationships, i.e. list_filter=('house__room__town',) as seen in http://code.djangoproject.com/ticket/3400 I have only tested this with a double foreign key relationship('house__room'), and it worked. It hasn't been tested in production, and the troubling part of this code is probably to use of 'deepcopy'. I do add those copies back to the options instance, so there shouldn't be too much runaway copying.
Having things like DATABASE_NAME in the admin interface is handy if you're working on development and deployment systems. Replace the template admin/base_site.html with the template code. The variables to be displayed in the admin need to be exported into the environment before running the server. The python code shown is an example of a wsgi handler, and the same format can be used in manage.py for the development server.