#16101: SingleObjectMixin should accept parameters for overriding the URL 
keywords
for pk and slug
----------------------------------------+-------------------------------
               Reporter:  AndrewIngram  |          Owner:  nobody
                   Type:  New feature   |         Status:  new
              Milestone:                |      Component:  Generic views
                Version:  1.3           |       Severity:  Normal
             Resolution:                |       Keywords:
           Triage Stage:  Accepted      |      Has patch:  0
    Needs documentation:  1             |    Needs tests:  1
Patch needs improvement:  0             |  Easy pickings:  0
----------------------------------------+-------------------------------
Changes (by julien):

 * needs_docs:  0 => 1
 * needs_tests:  0 => 1
 * stage:  Unreviewed => Accepted


Old description:

> Currently, in SingleObjectMixin, Django looks for a 'pk' or 'slug'
> keyword argument to use for looking up an instance of a model. You can
> override slug_field when the field on the model is something other than
> "slug". What you can't do is designate different URL keywords to use for
> these lookup, and to override this in a subclass the whole get_object
> method needs to be reimplemented.
>
> My proposition is to have a 'pk_keyword' and 'slug_keyword' field on
> SingleObjectMixin which default to 'pk' and 'slug' respectively, but can
> easily be overridden.
>
> Use case:
>
> I have a product app with a URL like this:
>
> /(r'^(?P<item_class_slug>[\w-]+)/(?P<item_slug>[\w-]*)-(?P<pk>\d+)/$'
>
> The view uses a subclass of DetailView with the pk keyword being used for
> fetching the product. But we also have optional product review URLs which
> are only included if the reviews app is installed, and are included like
> this:
>
> url(r'^(?P<item_class_slug>[\w-]+)/(?P<item_slug>[\w-]*)-(?P<pk>\d+)/',
> include(self.reviews_app.urls)),
>
> Within the reviews URLs we have a review detail view which also uses
> DetailView, this means I end up with two pk keywords in the URLs. Now I
> could just use a different keyword for the product pk keyword for this
> include, but I prefer consistency in my URL patterns. I would rather use
> 'item_pk' and 'review_pk' in all cases, which I can't currently do.
> I've had a look at the code and it seems like a straightforward change,
> I'm happy to submit the patch myself if this issue is accepted.

New description:

 Currently, in `SingleObjectMixin`, Django looks for a 'pk' or 'slug'
 keyword argument to use for looking up an instance of a model. You can
 override slug_field when the field on the model is something other than
 "slug". What you can't do is designate different URL keywords to use for
 these lookup, and to override this in a subclass the whole get_object
 method needs to be reimplemented.

 My proposition is to have a 'pk_keyword' and 'slug_keyword' field on
 `SingleObjectMixin` which default to 'pk' and 'slug' respectively, but can
 easily be overridden.

 Use case:

 I have a product app with a URL like this:
 {{{#!python
 r'^(?P<item_class_slug>[\w-]+)/(?P<item_slug>[\w-]*)-(?P<pk>\d+)/$'
 }}}
 The view uses a subclass of `DetailView` with the pk keyword being used
 for fetching the product. But we also have optional product review URLs
 which are only included if the reviews app is installed, and are included
 like this:
 {{{#!python
 url(r'^(?P<item_class_slug>[\w-]+)/(?P<item_slug>[\w-]*)-(?P<pk>\d+)/reviews',
 include(self.reviews_app.urls)),
 }}}
 Within the reviews URLs we have a review detail view which also uses
 `DetailView`, this means I end up with two pk keywords in the URLs. Now I
 could just use a different keyword for the product pk keyword for this
 include, but I prefer consistency in my URL patterns. I would rather use
 'item_pk' and 'review_pk' in all cases, which I can't currently do.
 I've had a look at the code and it seems like a straightforward change,
 I'm happy to submit the patch myself if this issue is accepted.

--

Comment:

 (Fixed the ticket description's formatting).

 Accepting as this seems like a simple and reasonable way of increasing
 `SingleObjectMixin`'s flexibility. Like for any new feature, the patch
 will need to include tests and documentation.

-- 
Ticket URL: <https://code.djangoproject.com/ticket/16101#comment:2>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Reply via email to