Re: Enhanced URL Resolver Match

[Russell Keith-Magee]

Hi Nowell,

My apologies for the lack of action on this -- I've been really busy
at work over the last month or so. I'm finally coming up for air, and
this ticket is high on my list of things to look at.

The patch itself looks like it's in pretty good shape; I just need to
pick apart the logic to make sure nothing has been missed.

Yours,
Russ Magee %-)

On Wed, Aug 4, 2010 at 8:37 PM, Nowell Strite  wrote:
> Hey Russ,
>
> Is there anything I should do to get 
> http://code.djangoproject.com/ticket/13922
> into RFC state? Let me know if you feel that the existing patch needs
> any work, or better docs.
>
> Thanks!
> Nowell
>
> On Jul 10, 4:35 am, Russell Keith-Magee 
> wrote:
>> On Fri, Jul 9, 2010 at 1:50 PM, Nowell Strite  wrote:
>> > When Django 1.1 was released URLs gained the ability to be nested with
>> > namespaces by adding "app_name" and "namespace" attributes to the
>> > include(...) functions within urls.py. The reverse(...) function was
>> > updated to allow you to specify namespace and current_app when
>> > resolving URLs, however, we never brought the resolve(...) function up
>> > to speed to include the relevant namespace and app_name data of the
>> > resolved URL. I have taken an initial stab with code and tests (minus
>> > documentation, until this feature is completed and agreed upon by the
>> > community).
>>
>> > In order to achieve this I have graduated the result of the
>> > resolve(...) method to be a ResolverMatch class as opposed to the old
>> > tuple(func, args, kwargs). I have also implemented this feature to
>> > provides backwards compatibility for the old "func, args, kwargs =
>> > resolve(...)" so this feature should hopefully be completely backwards
>> > compatible. The new ResolverMatch class provides access to all
>> > attributes of the resolved URL match such as (url_name, app_name,
>> > namespace, func, args, kwargs).
>>
>> > Please take a look and let me know what you think of the direction and
>> > implementation:
>>
>> >http://github.com/nowells/django/compare/master...resolver-match
>>
>> I'll need to do a detailed teardown before I commit, but on a first
>> inspection, this looks pretty good to me.
>>
>> If there isn't a ticket for this already, could you please open one
>> and include a reference to your github branch (and/or upload the
>> patch). Once there are some docs, I'm happy for this to be RFC for
>> 1.3.
>>
>> 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.
>
>

-- 
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: Enhanced URL Resolver Match

[Nowell Strite]

Hey Russ,

Is there anything I should do to get http://code.djangoproject.com/ticket/13922
into RFC state? Let me know if you feel that the existing patch needs
any work, or better docs.

Thanks!
Nowell

On Jul 10, 4:35 am, Russell Keith-Magee 
wrote:
> On Fri, Jul 9, 2010 at 1:50 PM, Nowell Strite  wrote:
> > When Django 1.1 was released URLs gained the ability to be nested with
> > namespaces by adding "app_name" and "namespace" attributes to the
> > include(...) functions within urls.py. The reverse(...) function was
> > updated to allow you to specify namespace and current_app when
> > resolving URLs, however, we never brought the resolve(...) function up
> > to speed to include the relevant namespace and app_name data of the
> > resolved URL. I have taken an initial stab with code and tests (minus
> > documentation, until this feature is completed and agreed upon by the
> > community).
>
> > In order to achieve this I have graduated the result of the
> > resolve(...) method to be a ResolverMatch class as opposed to the old
> > tuple(func, args, kwargs). I have also implemented this feature to
> > provides backwards compatibility for the old "func, args, kwargs =
> > resolve(...)" so this feature should hopefully be completely backwards
> > compatible. The new ResolverMatch class provides access to all
> > attributes of the resolved URL match such as (url_name, app_name,
> > namespace, func, args, kwargs).
>
> > Please take a look and let me know what you think of the direction and
> > implementation:
>
> >http://github.com/nowells/django/compare/master...resolver-match
>
> I'll need to do a detailed teardown before I commit, but on a first
> inspection, this looks pretty good to me.
>
> If there isn't a ticket for this already, could you please open one
> and include a reference to your github branch (and/or upload the
> patch). Once there are some docs, I'm happy for this to be RFC for
> 1.3.
>
> 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: Enhanced URL Resolver Match

[Nowell Strite]

Hey Nate,

This actually doesn't touch handling lazy reversing of urls, this
deals strictly with enhancing the result of the resolve(...) function
to provide more detail than just func, args, kwargs.

Nowell

On Jul 12, 9:57 am, Nate  wrote:
> If I'm not mistaken, this sort of lazy url reversing could make it
> possible to reverse URLs in settings, which has effect upon issues
> such as the following:
>
> http://groups.google.com/group/django-developers/browse_thread/thread...
>
> Is that correct?
>
> On Jul 11, 11:02 am, Nowell Strite  wrote:
>
>
>
>
>
>
>
> > Sounds great Russ. I have created a ticket for this 
> > issue:http://code.djangoproject.com/ticket/13922
>
> > Once you do a tear-down, and if things look good, let me know and I'll
> > start taking a stab at documentation.
>
> > Thanks!
> > Nowell
>
> > On Jul 10, 4:35 am, Russell Keith-Magee 
> > wrote:
>
> > > On Fri, Jul 9, 2010 at 1:50 PM, Nowell Strite  wrote:
> > > > When Django 1.1 was released URLs gained the ability to be nested with
> > > > namespaces by adding "app_name" and "namespace" attributes to the
> > > > include(...) functions within urls.py. The reverse(...) function was
> > > > updated to allow you to specify namespace and current_app when
> > > > resolving URLs, however, we never brought the resolve(...) function up
> > > > to speed to include the relevant namespace and app_name data of the
> > > > resolved URL. I have taken an initial stab with code and tests (minus
> > > > documentation, until this feature is completed and agreed upon by the
> > > > community).
>
> > > > In order to achieve this I have graduated the result of the
> > > > resolve(...) method to be a ResolverMatch class as opposed to the old
> > > > tuple(func, args, kwargs). I have also implemented this feature to
> > > > provides backwards compatibility for the old "func, args, kwargs =
> > > > resolve(...)" so this feature should hopefully be completely backwards
> > > > compatible. The new ResolverMatch class provides access to all
> > > > attributes of the resolved URL match such as (url_name, app_name,
> > > > namespace, func, args, kwargs).
>
> > > > Please take a look and let me know what you think of the direction and
> > > > implementation:
>
> > > >http://github.com/nowells/django/compare/master...resolver-match
>
> > > I'll need to do a detailed teardown before I commit, but on a first
> > > inspection, this looks pretty good to me.
>
> > > If there isn't a ticket for this already, could you please open one
> > > and include a reference to your github branch (and/or upload the
> > > patch). Once there are some docs, I'm happy for this to be RFC for
> > > 1.3.
>
> > > 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: Enhanced URL Resolver Match

[Nate]

If I'm not mistaken, this sort of lazy url reversing could make it
possible to reverse URLs in settings, which has effect upon issues
such as the following:

http://groups.google.com/group/django-developers/browse_thread/thread/fa3661888716f940

Is that correct?

On Jul 11, 11:02 am, Nowell Strite  wrote:
> Sounds great Russ. I have created a ticket for this 
> issue:http://code.djangoproject.com/ticket/13922
>
> Once you do a tear-down, and if things look good, let me know and I'll
> start taking a stab at documentation.
>
> Thanks!
> Nowell
>
> On Jul 10, 4:35 am, Russell Keith-Magee 
> wrote:
>
>
>
> > On Fri, Jul 9, 2010 at 1:50 PM, Nowell Strite  wrote:
> > > When Django 1.1 was released URLs gained the ability to be nested with
> > > namespaces by adding "app_name" and "namespace" attributes to the
> > > include(...) functions within urls.py. The reverse(...) function was
> > > updated to allow you to specify namespace and current_app when
> > > resolving URLs, however, we never brought the resolve(...) function up
> > > to speed to include the relevant namespace and app_name data of the
> > > resolved URL. I have taken an initial stab with code and tests (minus
> > > documentation, until this feature is completed and agreed upon by the
> > > community).
>
> > > In order to achieve this I have graduated the result of the
> > > resolve(...) method to be a ResolverMatch class as opposed to the old
> > > tuple(func, args, kwargs). I have also implemented this feature to
> > > provides backwards compatibility for the old "func, args, kwargs =
> > > resolve(...)" so this feature should hopefully be completely backwards
> > > compatible. The new ResolverMatch class provides access to all
> > > attributes of the resolved URL match such as (url_name, app_name,
> > > namespace, func, args, kwargs).
>
> > > Please take a look and let me know what you think of the direction and
> > > implementation:
>
> > >http://github.com/nowells/django/compare/master...resolver-match
>
> > I'll need to do a detailed teardown before I commit, but on a first
> > inspection, this looks pretty good to me.
>
> > If there isn't a ticket for this already, could you please open one
> > and include a reference to your github branch (and/or upload the
> > patch). Once there are some docs, I'm happy for this to be RFC for
> > 1.3.
>
> > 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: Enhanced URL Resolver Match

[Nowell Strite]

Sounds great Russ. I have created a ticket for this issue:
http://code.djangoproject.com/ticket/13922

Once you do a tear-down, and if things look good, let me know and I'll
start taking a stab at documentation.

Thanks!
Nowell

On Jul 10, 4:35 am, Russell Keith-Magee 
wrote:
> On Fri, Jul 9, 2010 at 1:50 PM, Nowell Strite  wrote:
> > When Django 1.1 was released URLs gained the ability to be nested with
> > namespaces by adding "app_name" and "namespace" attributes to the
> > include(...) functions within urls.py. The reverse(...) function was
> > updated to allow you to specify namespace and current_app when
> > resolving URLs, however, we never brought the resolve(...) function up
> > to speed to include the relevant namespace and app_name data of the
> > resolved URL. I have taken an initial stab with code and tests (minus
> > documentation, until this feature is completed and agreed upon by the
> > community).
>
> > In order to achieve this I have graduated the result of the
> > resolve(...) method to be a ResolverMatch class as opposed to the old
> > tuple(func, args, kwargs). I have also implemented this feature to
> > provides backwards compatibility for the old "func, args, kwargs =
> > resolve(...)" so this feature should hopefully be completely backwards
> > compatible. The new ResolverMatch class provides access to all
> > attributes of the resolved URL match such as (url_name, app_name,
> > namespace, func, args, kwargs).
>
> > Please take a look and let me know what you think of the direction and
> > implementation:
>
> >http://github.com/nowells/django/compare/master...resolver-match
>
> I'll need to do a detailed teardown before I commit, but on a first
> inspection, this looks pretty good to me.
>
> If there isn't a ticket for this already, could you please open one
> and include a reference to your github branch (and/or upload the
> patch). Once there are some docs, I'm happy for this to be RFC for
> 1.3.
>
> 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: Enhanced URL Resolver Match

[Russell Keith-Magee]

On Fri, Jul 9, 2010 at 1:50 PM, Nowell Strite  wrote:
> When Django 1.1 was released URLs gained the ability to be nested with
> namespaces by adding "app_name" and "namespace" attributes to the
> include(...) functions within urls.py. The reverse(...) function was
> updated to allow you to specify namespace and current_app when
> resolving URLs, however, we never brought the resolve(...) function up
> to speed to include the relevant namespace and app_name data of the
> resolved URL. I have taken an initial stab with code and tests (minus
> documentation, until this feature is completed and agreed upon by the
> community).
>
> In order to achieve this I have graduated the result of the
> resolve(...) method to be a ResolverMatch class as opposed to the old
> tuple(func, args, kwargs). I have also implemented this feature to
> provides backwards compatibility for the old "func, args, kwargs =
> resolve(...)" so this feature should hopefully be completely backwards
> compatible. The new ResolverMatch class provides access to all
> attributes of the resolved URL match such as (url_name, app_name,
> namespace, func, args, kwargs).
>
> Please take a look and let me know what you think of the direction and
> implementation:
>
> http://github.com/nowells/django/compare/master...resolver-match

I'll need to do a detailed teardown before I commit, but on a first
inspection, this looks pretty good to me.

If there isn't a ticket for this already, could you please open one
and include a reference to your github branch (and/or upload the
patch). Once there are some docs, I'm happy for this to be RFC for
1.3.

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.