variable view name in url tag

[Sean Brant]

I know this has come up over the last few years[1] and people are
mixed on the action that should be taken. I would like to bring it up
again as it has bitten me a few time lately.

I seems the biggest concern is backwards compatibility of the syntax.
I feel that should not stop us from fixing something that is an
annoying wart and also keeping the syntax in line with how other tags
work.

In this thread[2] Malcolm suggested introducing a new tag and
depreciating the old one which could be done by bringing something
like[3] into core. Im not huge on the idea of have 2 tags that do the
same thing only with slightly different syntax, but if that is the
cleanest upgrade I'm +1.

I think this can still be done in a backwards compatible way[4],
unless I'm missing something.

I hope this doesn't turn into a shed planing session, thanks!

[1] http://code.djangoproject.com/ticket/7917
[2]
http://groups.google.com/group/django-developers/browse_thread/thread/ac2b1ea4555c0a62/21cf9b1aed6d11e0?lnk=gst&q=url+tag+viewname#21cf9b1aed6d11e0
[3] http://github.com/ulope/django-reversetag
[4] http://pastebin.com/FhZSFQdn

[Russell Keith-Magee]

On Mon, Oct 4, 2010 at 4:53 AM, Sean Brant <brant...@gmail.com> wrote:
> I know this has come up over the last few years[1] and people are
> mixed on the action that should be taken. I would like to bring it up
> again as it has bitten me a few time lately.
>
> I seems the biggest concern is backwards compatibility of the syntax.
> I feel that should not stop us from fixing something that is an
> annoying wart and also keeping the syntax in line with how other tags
> work.
>
> In this thread[2] Malcolm suggested introducing a new tag and
> depreciating the old one which could be done by bringing something
> like[3] into core. Im not huge on the idea of have 2 tags that do the
> same thing only with slightly different syntax, but if that is the
> cleanest upgrade I'm +1.
>
> I think this can still be done in a backwards compatible way[4],
> unless I'm missing something.

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 %-)

[Sean Brant]

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.
>

[Russell Keith-Magee]

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 %-)

[Sean Brant]

On Oct 3, 8:08 pm, Russell Keith-Magee <russ...@keith-magee.com>
wrote:

> On Mon, Oct 4, 2010 at 8:56 AM, Sean Brant <brant.s...@gmail.com> wrote:
>
> > On Oct 3, 2010, at 7:37 PM, Russell Keith-Magee wrote:
>

Okay I created a new ticket with patch for this.
http://code.djangoproject.com/ticket/14389

> Yours,
> Russ Magee %-)

[Russell Keith-Magee]

On Tuesday, 5 October 2010 at 12:17 AM, Sean Brant wrote:

On Oct 3, 8:08 pm, Russell Keith-Magee <russ...@keith-magee.com>
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

Thanks Sean. I've put this on my todo list once I've sorted out major features for the alpha.

If you're in the area and you're feeling particularly enthused, it would be a nice idea to do an audit of all the other Django template tags to see if there are any other tags that need a similar migration plan. For example, I think #9666 describes the asme problem, but with the {% ssi %} tag. I can't think of any other examples off the top of my head, but it wouldn't surprise me if they exist.

If we're going to introduce a "from future" analog for template tags, it would be nice to get *all* the things that need to come from the future.

Yours,

Russ Magee %-)

[SmileyChris]

Just throwing the idea out there, it would be possible to keep the tag
completely backwards compatible by using a slightly different syntax
for variables.

Standard non-variable access stays the same: {% url home %}, {% url
edit-profile profile.pk %}

Variable access is done via a "var=" first argument: {% url
var=some_urlname %} , {% url var=client.edit_profile_urlname
profile.pk %}

> Okay I created a new ticket with patch for this.http://code.djangoproject.com/ticket/14389
>
>
>
>
>
>
>
> > Yours,
> > Russ Magee %-)

[Russell Keith-Magee]

On Tue, Oct 5, 2010 at 7:27 AM, SmileyChris <smile...@gmail.com> wrote:
> Just throwing the idea out there, it would be possible to keep the tag
> completely backwards compatible by using a slightly different syntax
> for variables.
>
> Standard non-variable access stays the same: {% url home %}, {% url
> edit-profile profile.pk %}
>
> Variable access is done via a "var=" first argument: {% url
> var=some_urlname %} , {% url var=client.edit_profile_urlname
> profile.pk %}

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 %-)