On 12 nov, 00:06, Russell Keith-Magee <russ...@keith-magee.com> wrote: > 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.
Perfect, because I would expect most of client code to define view classes like it's usually done with methods, with a fixed argument list. > 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. Ok, I understand that. I have no gripes on generic views accepting a variable argument list as long as it Just Works. My concern was if this should be the case for derived view classes too (which you already answered about redefining __init__). > 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.
