Snippet List
This custom test suite runner will record all of the URLs accessed during your test suite. It will compare it to the list of all URLs you have configured for your site and produce a report of any URLs missed. It requires that all URLs are named (using the ``name=`` parameter).
To use is, set the ``TEST_RUNNER`` variable in your configuration to this class. You can also define ignored URLs. For example, to filter out the admin URLs, you can use:
IGNORED_COVERAGE_URLS = ['^admin/',
'^admin/doc/']
- urlconf
- testing
- testrunner
This snippet is greatly inspired by [@jlorich](http://djangosnippets.org/users/jlorich/)'s useful [#2436](http://djangosnippets.org/snippets/2436/).
The main difference is that I wanted to choose the names of my URL params instead of being forced into naming them "value1", "value2", etc. When reversing the URL you have to remember that the kwargs aren't friendly. By using the same names in the `filters` list, you don't have to change the way your otherwise write the URL pattern. Also it's clear throughout how you'll be filtering the QuerySet.
The other change I made was "erroring early". This avoids running the QuerySet all over again inside `object_detail()` just to have it raise an exception we could have caught the first time.
- filter
- urlconf
- generic-views
- queryset
- urlpatterns
Apply a decorator to every urlpattern and URLconf module returned by Django's include() method . This allows you use a decorator on any number of views without having to decorate each one individually.
The use case here is wrapping all of the Django Admin with a superuser decorator. This is code that's better left alone where we can't actually go in and decorate the Admin views and urlpatterns manually. It's also almost guaranteed the Admin will include() other URL files. So the added bonus is all the INSTALLED_APPS that have their admin.py files registered by admin.autodiscover() will be decorated automatically as well.
This snippet is greatly inspired by [@miracle2k](http://djangosnippets.org/users/miracle2k/)'s excellent [#532](http://djangosnippets.org/snippets/532/). In the comments there @timbroder offers a modification to decorate includes but I think this is cleaner, simpler code and not subject to changes in the Django base code driving _get_url_patterns().
- urls
- urlconf
- decorator
- urlpatterns
- resolve
In the same vein as [snippet 436](http://www.djangosnippets.org/snippets/436/), this allows you to differentiate view logic by HTTP method such as GET, POST, PUT, DELETE.
This is also very useful combined with the [HttpMethodsMiddleware snippet](http://www.djangosnippets.org/snippets/174/).
I am not the author, but I have found it to be very helpful.
Sometimes, when views are particularly complex, it's useful to send the different request methods to different functions. If you have to do this frequently, the repetition gets tiring. This helper class can be used to simplify that.
Taken from the [longer description on my blog][1]:
> One of the great things about Django is its simple and flexible URL handling. If your Django work, like mine, includes converting existing sites, you’ll probably be doing some URL cleanup along the way...
Just plug your old/new URL pairs into `redirects`.
[1]: http://e-scribe.com/news/290
If you want to run multiple versions of a site from the same project IE a staging version and the live one, you need two settings and urlconf files.
1. make separate copies of settings_staging.py and urls_staging.py in the project dir.
2. Change SITE_ID and ROOT_URLCONF in settings_staging.py
3. Make extra include lines in the projects urls_staging.py like the example.
4. Add urls_staging.py to applications where you need extra urls. Make them just like you would normally do urls.py
Thanks to ronny for suggesting the double entries in urlconf.
11 snippets posted so far.