Snippet List
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
This is an expanded version of ["Resolve URLs to view name"](http://djangosnippets.org/snippets/1378/) without the monkey-patching.
Simply pass in a URL such as '/events/rsvp/some_conference/' and you'll get back the view name or function (if name isn't available) and the arguments to it, eg 'events_rsvp', [], {'event_slug':'some_conference'}.
Example (blatantly copied from previous snippet):
=== urlconf ====
urlpatterns = patterns(''
(r'/some/url', 'app.views.view'),
url(r'/some/other/(?P<url>\w+)', 'app.views.other.view', name='this_is_a_named_view'),
url(r'/yet/another/(?P<url>\w+)/(\d+)', 'app.views.yetanother.view', name='one_with_args'),
)
=== example usage in interpreter ===
>>> from some.where import resolve_to_name
>>> print resolve_to_name('/some/url')
('app.views.view',[],{})
>>> print resolve_to_name('/some/other/url')
('this_is_a_named_view',[],{'url':'url'})
>>> print resolve_to_name('/yet/another/url/5')
('one_with_args',[5],{'url':'url'})
From [fahhem.com](http://fahhem.com/) and [Recrec Labs](http://recreclabs.com/)
- url
- resolve
- name
- args
- kwargs
Add it to MIDDLEWARE_CLASSES and you will get request.current_view getting values like "connection.views.index" or "django.views.static.serve" - one example usage is to show different help text based on current view name.
EDIT: actually, you can use process_view middleware function where you automatically get current_view as first parameter.
- middleware
- view
- url
- resolve
Add these two middleware to the top of MIDDLEWARE_CLASSES.
Add BASE_DOMAIN to your setting file : BASE_DOMAIN = '.13.com'.
your root urlconf may like this:
urlpatterns = patterns('',
url(r'^www:(?P<id>[0-9]+)/$', 'couponcn.store.views.site_index', name='site_index'),
url(r'^news:abc/def/$', 'couponcn.store.views.site_index', name='site_index2'),
)
then
{% url site_index id=4 %}<br />
{% url site_index2 %}
in your template or the reverse function will work out urls like this:
http://www.13.com/4/
http://news.13.com/abc/def/
- url
- reverse
- resolve
- subdomain
There are times when you want to hook into the Variable class of django.template to get extra debugging, or even to change its behavior. The code shown is working code that does just that. You can monkeypatch template variable resolution by calling patch_resolver(). I recommend using it for automated tests at first.
My particular version of _resolve_lookup does two things--it provides some simple tracing, and it also simplifies variable resolution. In particular, I do not allow index lookups on lists, since we never use that feature in our codebase, and I do not silently catch so many exceptions as the original version, since we want to err on the side of failure for tests. (If you want to do monkeypatching in production, you obviously want to be confident in your tests and have good error catching.)
As far as tracing is concerned, right now I am doing very basic "print" statements, but once you have these hooks in place, you can do more exotic things like warn when the same object is being dereferenced too many times, or even build up a graph of object interrelationships. (I leave that as an exercise to the reader.)
If you want to see what the core _resolve_lookup method looks like, you can find it in django/templates/__init__.py in your installation, or also here (scroll down to line 701 or so):
[source](http://code.djangoproject.com/browser/django/trunk/django/template/__init__.py)
- template
- variable
- resolve
This code overrides the existing RegistrationForm in django-registration and adds a new validation step. In this step, the username (my example slug) is compared against all the existing URLs that the application currently resolves and, if it *does* successfully resolve, throws a validation exception. This indicates that the username chosen would be overriden (or, if you wrote your urls.py file badly, would override) an existing URL already recognized by your application.
A much longer explanation can be found at [Dynamic names as first-level URL path objects in Django](http://www.elfsternberg.com/2009/06/26/dynamic-names-as-first-level-url-path-objects-in-django/).
- registration
- slug
- reverse
- resolve
This snippet suplies a resolve_to_name function that takes in a path and resolves it to a view name or view function name (given that the path is actually defined in your urlconf).
Example:
=== urlconf ====
urlpatterns = patterns(''
(r'/some/url', 'app.views.view'),
(r'/some/other/url', 'app.views.other.view', {}, 'this_is_a_named_view'),
)
=== example usage in interpreter ===
>>> from some.where import resolve_to_name
>>> print resolve_to_name('/some/url')
'app.views.view'
>>> print resolve_to_name('/some/other/url')
'this_is_a_named_view'
** DEPRECATED**, use [django-reversetag @ github](http://github.com/ulope/django-reversetag/tree/master) instead.
If you want to be able to use context variables as argument for the "url" template tag this is for you.
Just put this code somwhere where it will be run early (like your app's _ _init_ _.py) and of you go.
Usage:
{% url name_of_view_or_variable arg1 arg2 %}
**NOTE:** This may possibly break your site!
Every view name that is passed to url will be tried to be resolved as a context variable first!
So if there is a variable coincidentally named like one of your views THEN IT WILL BREAK.
So far it works great for me, but keep an eye out for name clashes.
- template
- tag
- url
- context
- variable
- resolve
- resolving
9 snippets posted so far.