On Fri, Nov 12, 2010 at 9:09 AM, hcarvalhoalves <hcarvalhoal...@gmail.com> wrote: > To be fair, I only had one small pet peeve with the current views API > after trying the alpha: the use of self.args / self.kwargs. > > There's added value on being able to see which parameters a view > expects by seeing it's method signature: > > > def publisher(request, publisher_name): > publisher = get_object_or_404(Publisher, > name__iexact=publisher_name) > ... > > > As opposed to (from the release notes): > > > class PublisherBookListView(ListView): > ... > def get_queryset(self): > publisher = get_object_or_404(Publisher, > name__iexact=self.args[0]) > ... > > > Using keyword arguments help a little more, so you don't pass values > around blindly based on indexes only. Still, the keyword will be lost > somewhere in the middle of the method. It's a lot less clear than just > checking a method signature.
Thanks for the feedback. And what is your suggestion for fixing this? > In 1.x, I liked the fact of having reverse() automatically fail loud > when the method signature didn't matched my URL pattern. That helps to > catch a lot of views-urls mismatches. Can that behaviour be replicated > with the class-based API by overriding it's __init__, instead of > tucking parameters away on self.args/kwargs? Or there's really a > philosophy that views should just trust URL pattern matching? Yes, overriding a class to provide a specific list of keyword arguments to __init__ would work, and would provide the error handling you describe. As for whether views should just trust URL patterns: We're defining generic views. Introducing generic argument handling -- **kwargs -- is part of that pattern. When you make something more generic, one of the things you lose is specific error handling. Broadly speaking, what you're proposing sounds good to me. Tighter error handling is always a good thing, and the current API hasn't made an active decision to suppress error handling -- it's just a consequence of making views generic. However, we need a specific suggestion. If you can make a specific suggestion (preferably in the form of a patch), I'm happy to entertain that suggestion. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.