This isn't backwards compatible in every case. Consider:
{% url foo %}
foo could be:
- A URL pattern name
- A variable in the context
- A variable in the context *and* a URL pattern name
It's the third case where your proposal has problems. Under the
current implementation, it's *always* interpreted as a URL pattern
name. Under your proposal, the context variable would take precedence
in the third case.
It's also backwards incompatible in the second case (though not in a
way that matters as much): if you have an existing template that
raises an error, but you have a context variable that matches the name
you've used, your implementation *won't* raise an error.
However, there is another way (an alternative to adding a parallel tag) :-)
An interesting quirk/feature of Django's template language: if you
register template tags with the same name, the last registered name
wins.
This means we can define a "future_url" template tag library that
registers a {% url %} template tag. Then, in your code, you can say:
{% load future_url %}
{% url "url-name" foo=bar %}
and get the new behavior. Then, we can put PendingDeprecationWarnings
in the old {% url %} tag definition, upgraded to DeprecationWarnings
in 1.4. Then, in 1.5, we switch the behavior over and start
deprecating the future_url tag library.
I'm completely in favor of making this change; the behavior of the url
tag has always been an annoying wart, and it would be good to clean it
up.
Yours,
Russ Magee %-)
Thanks for the feedback Russ. I know it couldn't be that straight forward. I'll work on a patch this week that
implements what you mentioned. Would it be best to start a new ticket or re-open the old ticket?
> --
> You received this message because you are subscribed to the Google Groups "Django developers" group.
> To post to this group, send email to django-d...@googlegroups.com.
> To unsubscribe from this group, send email to django-develop...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
>
Open a new ticket. #7917 proposes fixing the existing tag; this is a
complete new approach to the problem. However, make sure you reference
the old ticket and discussions so we have a point of reference. Feel
free to accept the new ticket for the 1.3 milestone.
Yours,
Russ Magee %-)
On Tuesday, 5 October 2010 at 12:17 AM, Sean Brant wrote:
On Mon, Oct 4, 2010 at 8:56 AM, Sean Brant wrote:
> Thanks for the feedback Russ. I know it couldn't be that straight forward. I'll work on a patch this week that
> implements what you mentioned. Would it be best to start a new ticket or re-open the old ticket?
Open a new ticket. #7917 proposes fixing the existing tag; this is a
complete new approach to the problem. However, make sure you reference
the old ticket and discussions so we have a point of reference. Feel
free to accept the new ticket for the 1.3 milestone.
Okay I created a new ticket with patch for this.
http://code.djangoproject.com/ticket/14389
I don't deny that this would be backwards compatible. However, rather
than work around a syntactic wart, I'd rather fix it outright. {% load
future_urls %} gives us an 18 month window (or so) during which; 36
months if we replace future_urls with old_urls when we do the
switchover.
Yours,
Russ Magee %-)