On Tue, Dec 27, 2011 at 9:39 PM, Andre Terra <[email protected]> wrote: > On Tue, Dec 27, 2011 at 6:35 AM, Anssi Kääriäinen <[email protected]> > 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"). > > To be honest, I prefer the name "field_lookup". When I read "slug" I think > of blogs, and aside from CBVs, I think that every time [1] we use the word > "slug" anywhere in the docs or API, we are mentioning a blog-like example or > the admin SlugField.
The reason for the "slug" name is historical -- the old function-based generic view used "slug", so the new view inherited the same name. >From a documentation point of view, this is vaguely helpful, because you can't just use any field -- it needs to have certain properties (uniqueness, indexability, etc). Personally, my inclination would be to handle this as a documentation fix, pointing out that "slug_field" is technically just the kwarg that will be used on a query to find a unique object instance. The alternatives are to find "one true name" that will satisfy all use cases (which I don't think exists), or make the implementation of get_slug_field much more complex to support an edge use case. I'd prefer to keep the implementation simple but flexible, and the name historically consistent. Yours, Russ Magee %-) -- 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.
