django 1.3 url template tag and class-based views

Question

I'm just starting to migrate an app I have to 1.3 from 1.1.

I'm starting to get in the thick of class based views and am blown away, but not really in a good way.
I have some gripes but the specific question here is:

Is this the only way i can use the url template tag with a generic class-based view?
Django reverse url with parameters to a class based view
ie having to name every single url entry?

It seems ridiculous to me as one of the fundamental philosophies of Django is DRY and yet here we are.... RY-ing.....

Thanks in advance.

Edit:
So I have https://gist.github.com/1877374

and get the error TemplateSyntaxError Caught NoReverseMatch while rendering: Reverse for 'views.HomeView.as_view' with arguments '()' and keyword arguments '{}' not found.

Am I using this incorrectly?

---

Tangent:
I'd like to explain a little bit more about why I believe we are RY-ing if we have to name every single entry in the urls.py file

my urls.py typically looks like https://gist.github.com/1877462

I understand completely about decoupling.
The point here is that we have the ability to do so when required . I absolutely use the name feature, when i need to. Otherwise, why would i want to spend the time and energy to redundently add url to every entry and name every entry when often they will be the same as the name of the class/funciton in views.py?

Maybe this should be branched into a seperate question on SO.

Answer 1

First, this is not repeating yourself. Where are you naming the URL twice? That would be repeating yourself.

Second, naming of url patterns is not required - but offers many advantages - which is why it is recommended. It also provides you the flexibility of changing your view method names without having to change your templates. You can decide on a set of url names and hand them off to your designer to work on the templates, and you are free to name your view methods (or classes) the way you like.

Third, you need to pass the full path to the view method - so it needs to be as_view for class-based views and make sure you pass the correct number and type of arguments; and don't mix positional and keyword arguments.

Or, you can avoid most of the above by naming your URL patterns.

Answer 2

Here's a rather hand-waving explanation of why you can't reverse the class based views without naming them. I'm not really familiar with the Django internals, so I'm happy to be corrected.

With a function based view,

# my_app.views.py
def my_view(request):
    return HttpResponse("Hello, world!")

you can reverse my_app.views.my_view , because it is the path of a callable view function.

With a class based view,

# my_app.views.py
class MyView(TemplateView):
    template_name = "hello_world.html"

you can't reverse my_app.views.MyView , because it isn't a callable view object. The callable view is MyView.as_view() . If you assigned MyView.as_view() to a variable in your views as follows:

# my_app.views.py
class MyView(TemplateView):
    template_name = "hello_world.html"
my_view = MyView.as_view()

# urls.py
url('^$', `my_view`),

then you would be able to reverse my_view without naming it. This option is just as much repeating as naming your url, so I don't think you'll like it!.

However when you put MyView.as_view() directly in your url pattern, it's an anonymous function. It hasn't been assigned to any variable, so there is no path you can use to reverse it. Similarly, you wouldn't be able to reverse the following:

url('^$', lambda request: HttpResponse("Hello, World!")), 

Note that url() is basically just a function that makes it easier to add named url patterns. If you really don't want to name your urls, you could write your own function that automatically generates names for you.

Answer 3

I don't see how this is violating the DRY principle - they are all separate views that do different things and they are each being given a unique identifier so as not to collide when being reversed. If anything, using named URLs will reduce the code you have to write at the template level and make your url scheme far more readable