While working on some URL-related issues, I ran across a pretty big
problem with having ``{% url %}`` propagate ``NoReverseMatch`` up into
the templates: if it does that, there's no way to have "optional"
links. The perfect example is #7810 and the admin docs: if the URLs
for the admin doc views are installed, the admin should show a
(correct) link to the docs; if they're not installed, the link
shouldn't be there. Unfortunately, with the current ``url`` tag, there
isn't any way to make this work.
I started poking at it, and it turned out to be *very* easy to add a
``{% url ... as varname %}`` syntax to capture the URL into a variable
for later use. As a side effect, I made this syntax *not* raise errors
but instead return an empty string. This makes for a very natural
use::
{% url django-admindocs-docroot as docroot %}
{% if docroot %}
<a href="{{ docroot }}">Documentation</a>
{% endif %}
Patch here: http://code.djangoproject.com/git/?p=django;a=commitdiff;h=6c7d85a3cf6a3c7b161d960f86ea1cb111ded605
So: I know this is technically a "feature addition," but it makes the
fixes to some silly bugs far easier. Are there any objections to me
sneaking this into 1.0?
Jacob
+1 for this, before I test if someone already knows the answer, is it
possible to use this var in blocktrans?
{% url args as myurl %}
{% blocktrans %}
foo <a href="{{ myurl }}">baz</a>
{% endblocktrans %}
That's potentially the best solution for the endless discussion about
urls in blocktrans.
Best,
David
+1 -- Pinax could deprecate {% captureas %} with this feature. Seems
like a non-intentional pro :)
--
Eduardo de Oliveira Padoan
http://djangopeople.net/edcrypt/
http://whoisi.com/p/514
http://pinax.hotcluboffrance.com/profiles/edcrypt/
> Are there any objections to me
> sneaking this into 1.0?
Hell, no! That's perfect and also works with blocktrans.
..and let's us kill that captureas in Pinax, yay!
Cheers,
Jannis