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 %}
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?
> 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::
> 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?
+1 for this, before I test if someone already knows the answer, is it possible to use this var in blocktrans?
On Fri, Aug 29, 2008 at 12:43 PM, David Larlet <lar...@gmail.com> wrote:
> Le 29 août 08 à 17:18, Jacob Kaplan-Moss a écrit :
>> Hi folks --
>> 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::
>> 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?
> +1 for this, before I test if someone already knows the answer, is it > possible to use this var in blocktrans?
