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:
>
> >> 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?
>
> 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
> Yours,
> Russ Magee %-)
--
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.
