[patch] Tag for URL reverse lookup

Patch

Support for kwargs

Added support for keyword arguments in {% url %}, docstring updated.

However I have a hard time figuring out how to write tests for this thing. The tag uses current urlconf from settings to do its job and I'm not sure if it would be correct to replace it with special testing urls.py and views.py... So for now there are no tests for {% url %} in the patch.

Very usefull tag. I would propose a small change though. In the render function you prepend the project_name to the viewname (return reverse(project_name + '.' + self.view_name, args=args, kwargs=kwargs)).

However, this assumes that the application is part of the project (in the python sense). If the app is in a python package that is NOT the current project this aproach fails. This could be the case if you 'borrow' an application from another project (without copying it).

For example, I have an 'library project' (magicstrings) that contains various apps, used by different projects. The actual projects are little more than configuration and some very project-specific code. Thus the python path to a view in one of the apps part of Magic Strings is in my case (regardless of the project they are actually used in) magicstrings.app_name.views.view_name. And this patch puts, wrongly, the name of the actual project in front of that.

Another example is contrib. If you try to reverse map django.contrib.admin.views.main.index, this approach would try to reverse map current_project.django.contrib.admin.views.main.index, which would obviously fail.

There are imo two solutions: a) let people always specify the projectname or b) perhaps it is an idea to change the tag so that you can add the projectname in front of the path, separated by e.g. a colon. Option a) is the simplest, but perhaps I miss the reason behind the current behavior and is b) the only option.

{% url my_project:app_name.views.view_name %}

Would result in reverse('my_project.app_name.views.view_name'), and if projectname is ommited, fallback to the current one:

{% url app_name.views.view_name %}

Would result in reverse('current_project.app_name.views.view_name')

Rgds, Jeroen

First of all thank you for a very useful comment!

You wrote: "perhaps I miss the reason behind the current behavior".

The only reason is that I indeed wrongly had in mind only project's local views.

Looking at your proposals I can think of a third way that can be both short for in-project views and suitable for out-of-project views. It'll be like this:

1. try to import specified path without modifications
2. if that fails, add the project name and try again

I'll make an updated patch shortly.

Support for referring views outside project

Good solution. Thanks!

This is very nice. Can you please add unit tests and documentation so we can check this in?

I have a problem making a unit test for it. Every other template tag can be tested on its own but {% url %} actually needs urls.py and views.py... I can't think of a good way to fake this environment.

As for the docs, I'll post the patch shortly. Thanks!

I've wrapped my head around testing and made a new patch (2606.4.diff) with tests and documentation.

The patch requires 2 new files (attached). I tried to include them in the patch itself but couldn't apply it then, so I decided to attach them as is.

Patch + docs + tests

tests/regressiontests/templates/views.py

tests/regressiontests/templates/urls.py

I think this is just awaiting some brief documentation, but looks good to go.

It does have docs right in the patch :-). (the last one -- 2606.4.diff)

And to get you on course: two attached files views.py and urls.py are for tests. I didn't include them in the patch because I beleive they wouldn't be created by the 'patch' tool itself. But may be I'm mistaken :-)

Ahh. Didn't scroll down that far. Now that I know what this does, I like it very much.

(In [4494]) Fixed #2606 -- Added tag for working out the URL of a particular view function. All work done by Ivan Sagalaev.