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. I originally refrained from suggesting a different name because I wanted to avoid deprecating current functionality, but in hindsight I realize that if the attribute's name is not good, then renaming is the adequate solution. I may have been influenced by Alex Gaynor's django-filter [2] which I've used extensively, but considering he's said it himself that his app's API needs refactoring, then maybe a single field name would be preferable indeed. Creating a "lookup" attribute would simply add to the confusion. On Tue, Dec 27, 2011 at 10:56 AM, Andrew Ingram <[email protected]> wrote: > I'm trying to understand what your use case would be. SingleObjectMixin is > designed to only ever give you one object back (though I'm surprised it > doesn't handle the MultipleObjectsReturned exception), so out of all the > lookup choices we have, only an exact match on a unique field makes sense. > Am I missing something here? > For one, we currently don't address the use of "__iexact", although that could be fixed with a note in the docs. Off the top of my head, without looking at all the lookups allowed by filter() and without even coming up with a proof of concept, I assume it could be possible for one to want to find an object based on a related model from a view. This would also need to be addressed in the docs somehow and, again, a name like "field_lookup" sounds closer to that functionality than "slug_field". Considering how CVBs are still at an early stage, now's the time to review the API, in my opinion. In the process, we can come up with a way to handle MultipleObjectsReturned like Andrew suggested. Is it time for a new ticket yet? Cheers, André Terra (airstrike) [1] https://docs.djangoproject.com/search/?q=slug&release=1 [2] https://github.com/alex/django-filter/blob/master/django_filters/filters.py#L53 -- 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.
