How about renaming the slug_field to something more generic, slug_lookup
perhaps? (field + possibly the needed lookup). Keep the old one around
just for compatibility (or deprecate it, with a warning of: use
"slug_lookup instead").
The documentation of kwargs to .filter() says that the lookup refers to
the whole left-side string:
field_pt1__field__pt2...__lookuptype
[1] So, having slug_field and slug_lookup would be inconsistent, instead
you should have slug_field and slug_lookuptype. On the other hand,
lookup does sometimes refer to just the lookup type, as seen here. [2]
All in all, I don't see the reason to separate the lookup into two
parts, as I tend to think the whole left hand side as one string instead
of field references + lookup. As far as I know, there aren't many places
which do this splitting.
- Anssi
[1] https://docs.djangoproject.com/en/dev/topics/db/queries/#field-lookups
[2]
https://docs.djangoproject.com/en/dev/ref/models/querysets/#field-lookups
On 12/26/2011 09:01 PM, Andre Terra wrote:
Hello everyone,
I asked around in #django-dev but nobody had much to say, so I decided
to come here instead.
Currently, developers writing class-based views[0] use
SelectObjectMixin[1] to define which object will be handled by a given
single-object view instance (e.g. DetailView).
If I am understanding things correctly, this mixin has, among other
things, a slug_field class attribute which specifies in which model
field django should look for the value of slug, which is an instance
attribute usually filled with a value from a url pattern argument.
Ideally, users should also be able to define the lookup used by django
to find the slug. The current implementation passes slug_field as
kwarg to a .filter()call[2]. This means that views can be written so
that slug_field actually contain a lookup component (e.g. slug_field =
foo_iexact), but this behavior is, IMHO, not obvious to anyone who
hasn't read the source. The docs currently read:
"The name of the field on the model that contains the slug. By
default, slug_field is 'slug'."
... which actually suggest slug_field *must* match a model field, at
least for those of us who tend to just skim the docs as needed.
I propose we add a "lookup" attribute which defaults to "__exact" (for
backwards-compatibility as well as avoiding surprises) and is combined
with slug_field in the filter call so that users can customize the
filter kwarg in an elegant fashion. Before reading the source code
carefully, I had written my own mixin that just used string formatting
(i.e. "%s_%s" % (slug_field, lookup)") to handle this, and I liked how
it looked. I am, however, more than willing to take a different route
should anyone suggest it.
Another solution would be to keep the current code as is, and just add
a note in the docs regarding the flexibility of slug_field. Given that
the attribute name does say *field*, I'm not too fond of this approach.
Again, I'm willing to hear any feedback on this matter, as well as
writing patches and tests, as I expect them to be quite simple and
therefore within my abilities.
Cheers,
André Terra (airstrike)
[0] https://docs.djangoproject.com/en/dev/ref/class-based-views/
[1]
https://docs.djangoproject.com/en/dev/ref/class-based-views/#django.views.generic.detail.SingleObjectMixin
[2]
https://code.djangoproject.com/browser/django/trunk/django/views/generic/detail.py#L40
--
You received this message because you are subscribed to the Google
Groups "Django developers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
--
You received this message because you are subscribed to the Google Groups "Django
developers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
