On Oct 3, 2010, at 7:37 PM, Russell Keith-Magee wrote:
> On Mon, Oct 4, 2010 at 4:53 AM, Sean Brant <brant.s...@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 %-)
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-develop...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
