Hi Calvin, I can think of a few reasons. > - you've changed models or fields internally through migrations, but need > to continue supporting old URLs. > - you don't like the internal name to be exposed > - you have different models but want to expose a consistent URL pattern.
Those attributes control the URL kwargs that are used in the regex, we're not talking about URL query parameters or anything else that's visible to the end-user. Internal names aren't being exposed anywhere, and there'd be no issue with updating field names and continuing to support the URLs that reference them. Having said that, you're probably correct that I've overstated point (1) - There might be some circumstances where the developer would prefer to use 'slug' as the regex kwarg, but look up against a differently named model field. I'd still think that there's a very strong argument to be made that we could consider that a corner case that requires overriding `get_object`, in exchange for having a simpler API for the standard case. There would of course be other alternatives such as using both `lookup_field` and `lookup_kwarg` with the later defaulting to the same as the former if unset, but I'm not wild about something like that given that the intention of this proposal is to try to slightly slim down an aspect of the API. On Monday, 22 April 2013 12:37:32 UTC+1, Calvin Spealman wrote: > > > On Apr 22, 2013 7:15 AM, "Tom Christie" <christ...@gmail.com <javascript:>> > wrote: > > > > I'd be interested to know what you folks think of this proposal. > > > > SingleObjectMixin currently exposes these three attributes and one > method all dealing with queryset filter arguments... > > > > * pk_url_kwarg = 'pk' > > * slug_field = 'slug' > > * slug_url_kwarg = 'slug' > > * get_slug_field() > > > > I was wondering if it would be worth considering simplifying the API > somewhat, by moving those three attributes, and that method, into a > PendingDeprecation state, and replacing their usage with a single attribute > instead, that is used both as the URL kwarg, and as the queryset filter. > > > > * lookup_field = 'pk' > > > > That'd (eventually) lead to a simpler get_object implementation > internally, and (immediately) present a slightly nicer, simpler API. > > > > It'd be marginally different in that slug based lookups would require an > explicit `lookup_field = 'slug'` to be added to the view, > > and also in that it wouldn't handle the case of `slug_field` being set > to a different value from `slug_url_kwarg`. > > > > Personally I don't see the later being an issue as: > > > > 1. It's not clear to me why you'd ever *need* to use a URL kwarg that's > not the same as the filter arg. > > I can think of a few reasons. > - you've changed models or fields internally through migrations, but need > to continue supporting old URLs. > - you don't like the internal name to be exposed > - you have different models but want to expose a consistent URL pattern. > > > 2. If it's really something you need to do, then overriding get_object > is still really simple, as well as being nice and explicit... > > > > get_object(self, queryset): > > if queryset is None: > > queryset = self.get_queryset() > > return get_object_or_404(queryset, ...) # whatever custom lookup > behavior you need. > > > > To me, the main trade-off seems to be - Is the resulting API enough of > an improvement to be worth the change? > > > > Any opinions? > > > > Tom > > > > As an aside, is the discussion group considered the correct place for > API-changing proposals like this, or should I just raise them straight to > the ticket tracker? > > > > -- > > You received this message because you are subscribed to the Google > Groups "Django developers" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to django-develop...@googlegroups.com <javascript:>. > > To post to this group, send email to > > django-d...@googlegroups.com<javascript:> > . > > Visit this group at > http://groups.google.com/group/django-developers?hl=en. > > For more options, visit https://groups.google.com/groups/opt_out. > > > > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
