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 %}
On Oct 5, 5:17 am, Sean Brant <brant.s...@gmail.com> 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 <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.
