Re: [Feature Request] DetailView, DeleteView, UpdateView should not work with only slug and primary key field?
Thanks for this information On Wednesday, January 2, 2019 at 1:24:00 PM UTC+1, Osezele Orukpe wrote: > > Django class based generic views like DetailView, DeleteView and > UpdateView should be flexible enough to work with any unique field not just > slug and primary key field, > In real projects primary key and slugs are not used fetch data, a more > abstract unique key is preferred. > Yes, this can be easily done on our own but django can just ease that > extra stress by making these generic classes flexible enough to work with > any field of our choice in > the model given that the field is flagged as a unique field. > > so we could just use the DatailView as so: > > ProductDetail(DetailView): > model = Product > field = order_id > > instead of having to write a custom query(with the ORM) to fetch with > 'order_id' > > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/aee6866a-775f-4b5f-b059-2c9fb0cd5321%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Feature Request] DetailView, DeleteView, UpdateView should not work with only slug and primary key field?
>
> In real projects primary key and slugs are not used fetch data, a more
> abstract unique key is preferred.
In my experience it's normally primary key that is used. In a recent
project, I've used hashid fields as primary keys to avoid the problem of
leaking database PK's, which is the main motivation to use other keys:
https://github.com/nshafer/django-hashid-field
What you're suggesting isn't much code and the existing view hierarchy lets
you add it pretty easily in your own DetailView class by overriding just
get_object, something like (untested):
from django.views.generic import DetailView as BaseDetailView
class GetObjectByFieldMixin(object):
def get_object(self, queryset=None):
if queryset is None:
queryset = self.get_queryset()
try:
return queryset.get(**{self.field: self.kwargs['field_id']})
except queryset.model.DoesNotExist:
raise Http404('...')
class DetailView(GetObjectByFieldMixin, BaseDetailView):
pass
I am also one of several who believe the built-in class based views are
complicated enough and I would be against increasing this complexity when
it's easy enough to override for your project.
I'd also like to point out Tom Christie's project
http://django-vanilla-views.org/ which I've used and have helped maintain,
it has a simpler class-based view hierarchy and has built-in support for
what you want (at the expense of ditching Django's pk-or-slug-or-both
options). With it you can do something like:
from vanilla import DetailView
from myapp.models import Product
class ProductDetail(DetailView):
model = Product
lookup_field = 'order_id'
HTH!
On Wed, 2 Jan 2019 at 10:58, Osezele Orukpe wrote:
> Django class based generic views like DetailView, DeleteView and
> UpdateView should be flexible enough to work with any unique field not just
> slug and primary key field,
> In real projects primary key and slugs are not used fetch data, a more
> abstract unique key is preferred.
> Yes, this can be easily done on our own but django can just ease that
> extra stress by making these generic classes flexible enough to work with
> any field of our choice in
> the model given that the field is flagged as a unique field.
>
> so we could just use the DatailView as so:
>
> ProductDetail(DetailView):
> model = Product
> field = order_id
>
> instead of having to write a custom query(with the ORM) to fetch with
> 'order_id'
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/25f67fd1-4dfa-439d-91c6-356716da950b%40googlegroups.com
>
> .
> For more options, visit https://groups.google.com/d/optout.
>
--
Adam
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/CAMyDDM3LsVvjYJQfXiJu9KNaPbpES5Vm6biKUr%3DREZz5hEH9%2BA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: [Feature Request] DetailView, DeleteView, UpdateView should not work with only slug and primary key field?
Hi,
You can already use any unique field as the slug field, for example:
path('product//', views.ProductDetail.as_view()),
ProductDetail(DetailView)
model = Product
slug_field = 'order_id'
If you want to use a different name in the URL pattern, then
set slug_url_kwarg [1].
path('product//', views.ProductDetail.as_view()),
ProductDetail(DetailView)
model = Product
slug_field = 'order_id'
slug_url_kwarg = 'order_id'
Cheers,
Alasdair
On Wednesday, 2 January 2019 12:24:00 UTC, Osezele Orukpe wrote:
>
> Django class based generic views like DetailView, DeleteView and
> UpdateView should be flexible enough to work with any unique field not just
> slug and primary key field,
> In real projects primary key and slugs are not used fetch data, a more
> abstract unique key is preferred.
> Yes, this can be easily done on our own but django can just ease that
> extra stress by making these generic classes flexible enough to work with
> any field of our choice in
> the model given that the field is flagged as a unique field.
>
> so we could just use the DatailView as so:
>
> ProductDetail(DetailView):
> model = Product
> field = order_id
>
> instead of having to write a custom query(with the ORM) to fetch with
> 'order_id'
>
>
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/ffa51fce-b9c8-4d52-bb10-fd75ff503bd0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[Feature Request] DetailView, DeleteView, UpdateView should not work with only slug and primary key field?
Django class based generic views like DetailView, DeleteView and UpdateView should be flexible enough to work with any unique field not just slug and primary key field, In real projects primary key and slugs are not used fetch data, a more abstract unique key is preferred. Yes, this can be easily done on our own but django can just ease that extra stress by making these generic classes flexible enough to work with any field of our choice in the model given that the field is flagged as a unique field. so we could just use the DatailView as so: ProductDetail(DetailView): model = Product field = order_id instead of having to write a custom query(with the ORM) to fetch with 'order_id' -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/25f67fd1-4dfa-439d-91c6-356716da950b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
