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 <nathaniel.soa...@gmail.com> 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 <now...@strite.org> 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 <russ...@keith-magee.com> > > wrote: > > > > On Fri, Jul 9, 2010 at 1:50 PM, Nowell Strite <now...@strite.org> 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.
