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