Added `SingleObjectMixin.lookup_field`. #1205

Closed
wants to merge 5 commits into
from

Conversation

Projects
None yet
3 participants
Member

tomchristie commented May 23, 2013

Deprecates pk_url_kwarg, slug_url_kwarg, and slug_field.

References trac20342.

Quoting the trac ticket...

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.

docs/releases/1.6.txt
+should be used for object lookups, and should also correspond with a named
+argument in the URLconf.
+
+The default value for the ``slug_field`` attribute is ``'pk'``. If you are
@mjtamlyn

mjtamlyn May 23, 2013

Member

lookup_field?

Member

mjtamlyn commented May 23, 2013

Whilst I appreciate the API simplification, and I agree that the current number of field is a bit excessive, I am quite strongly against having to explicity set slug every time you want to use it. To me, this is, and maybe should be the more normal use case than pk in general web development. Django is quite strongly in favour of nice urls and provides all these helpers for creating and using slugs, it seems weird to me that we should remove this default behaviour. I know this results in more magic, but it makes a vastly smoother upgrade process for most users and also doesn't discourage what to me is a better practice.

docs/releases/1.6.txt
+
+In previous versions, object lookup in the :class:`DetailView` was controlled
+by the ``pk_url_kwarg``, ``slug_field``, and ``slug_url_kwarg`` attributes.
+These have now been replaced with a single ``slug_field`` attribute.
@bmispelon

bmispelon May 23, 2013

Member

slug_field should be lookup_field, no?

docs/releases/1.6.txt
+These have now been replaced with a single ``lookup_field`` attribute.
+
+The ``lookup_field`` attribute should correspond with the model field that
+should be used for object lookups, and should also correspond with a named
@bmispelon

bmispelon May 23, 2013

Member

I'm not a native speaker, but isn't there one "should" too many?

The lookup_field attribute should correspond with the model field that should be used for object lookups...

Member

tomchristie commented May 23, 2013

I guess it's really a matter of design style - I'd personally really like to see the GCBVs move to a simpler, more explicit API where possible, and this feels like one of the lower hanging fruits.

From my point of view it's actually beneficially to have to specify lookup_field = 'slug' in the slug field case. It's trivial to add to the view, makes the underlying behavior more obvious, and helps clean up the API. Cases like lookup_field = 'username' or lookup_field = 'uuid' are also less jarring than the corresponding slug_field = 'username' case, where 'slug' is used in the URLconf, but 'username' is used as the lookup field.

Having said that, there's clearly validity in sticking with the existing style. It works out-of-the box for the two most common cases, and I'm sure there'd be some complaints about the required explicitness if this change did make it in.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment