Enhanced URL Resolver Match

[Nowell Strite]

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

You can review the diff for this proposal on GitHub.

​http://github.com/nowells/django/compare/master...resolver-match

As well as check out the code:

​http://github.com/nowells/django/tree/resolver-match

Thanks!
Nowell Strite

[Nowell Strite]

The discussion for this topic can be viewed on Django-Dev at: ​http://groups.google.com/group/django-developers/browse_thread/thread/a1fb87e997fc923

[Nowell Strite]

Patch against trunk (created from the referenced GitHub branch)

[Russell Keith-Magee]

(In [13479]) Fixed #13922 -- Updated resolve() to support namespaces. Thanks to Nowell Strite for the report and patch.

[Russell Keith-Magee]

For future reference, here's the minor changes between the most patch and what got submitted:

• PEP8: [var] , not [ var ]
• Passing in [] as a default argument is a no-no (e.g., namespaces=[]). Instead, pass in None and check for the default value. If you use [] as a default variable, you can get some interesting bugs. The default value is only instantiated once, so it's possible to accidentally modify it over time, and as a result the 'default' value for the function can change.
• A light cleanup of the docs.
  • Fully documenting the ResolverMatch class
  • Rephrasing the 'versionchanged' notice.
• Added some extra test cases to catch the unnamed arguments cases. What caught my eye was that all the test cases were expecting tuple() as the value for args.
• Added some documentation annotating the tests that are being run.
• Dropped the 'reverse()' method of ResolverMatch. It wasn't tested, and it doesn't make much sense to me for a return value to need a method to return the original input.
• For the sake of being explicit, I've added tests that match can be assigned to a triple. This is implied by the 'legacy' tests, but better to be explicit with a common use case.

[Jacob]

Milestone 1.3 deleted