Re: variable view name in url tag

2010-10-04 Thread Russell Keith-Magee
On Tue, Oct 5, 2010 at 7:27 AM, SmileyChris  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 %-)

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



Re: variable view name in url tag

2010-10-04 Thread 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 %}

On Oct 5, 5:17 am, Sean Brant  wrote:
> On Oct 3, 8:08 pm, Russell Keith-Magee 
> wrote:
>
>
>
>
>
>
>
>
>
> > On Mon, Oct 4, 2010 at 8:56 AM, Sean Brant  wrote:
>
> > > On Oct 3, 2010, at 7:37 PM, Russell Keith-Magee wrote:
>
> > >> On Mon, Oct 4, 2010 at 4:53 AM, Sean Brant  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.



Re: variable view name in url tag

2010-10-04 Thread Russell Keith-Magee



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

On Oct 3, 8:08 pm, Russell Keith-Magee 
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..s...@gmail.com>.s...@gmail.com>Okay I created a new ticket with 
patch for this.http://code.djangoproject.com/ticket/14389Thanks 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 %-)

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



Re: variable view name in url tag

2010-10-04 Thread Sean Brant


On Oct 3, 8:08 pm, Russell Keith-Magee 
wrote:
> On Mon, Oct 4, 2010 at 8:56 AM, Sean Brant  wrote:
>
> > On Oct 3, 2010, at 7:37 PM, Russell Keith-Magee wrote:
>
> >> On Mon, Oct 4, 2010 at 4:53 AM, Sean Brant  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.



Re: variable view name in url tag

2010-10-03 Thread Russell Keith-Magee
On Mon, Oct 4, 2010 at 8:56 AM, Sean Brant  wrote:
>
> On Oct 3, 2010, at 7:37 PM, Russell Keith-Magee wrote:
>
>> On Mon, Oct 4, 2010 at 4:53 AM, Sean Brant  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.

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.



Re: variable view name in url tag

2010-10-03 Thread Sean Brant

On Oct 3, 2010, at 7:37 PM, Russell Keith-Magee wrote:

> On Mon, Oct 4, 2010 at 4:53 AM, Sean Brant  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.



Re: variable view name in url tag

2010-10-03 Thread Russell Keith-Magee
On Mon, Oct 4, 2010 at 4:53 AM, Sean Brant  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 %-)

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



variable view name in url tag

2010-10-03 Thread 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=url+tag+viewname#21cf9b1aed6d11e0
[3] http://github.com/ulope/django-reversetag
[4] http://pastebin.com/FhZSFQdn

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