On Tue, Dec 27, 2011 at 9:39 PM, Andre Terra wrote:
> On Tue, Dec 27, 2011 at 6:35 AM, Anssi Kääriäinen
> wrote:
>>
>> 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 d
On Tue, Dec 27, 2011 at 6:35 AM, Anssi Kääriäinen
wrote:
> 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").
On 26 Dec 2011, at 19:01, Andre Terra wrote:
> 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 fashio
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
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 unders
