-
Notifications
You must be signed in to change notification settings - Fork 2
/
Copy pathBasic.txt
37 lines (16 loc) · 2.3 KB
/
Basic.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
Basic settings:
The following attributes control the basic view behavior.
queryset - The queryset that should be used for returning objects from this view. Typically, you must either set this attribute, or override the get_queryset() method. If you are overriding a view method, it is important that you call get_queryset() instead of accessing this property directly, as queryset will get evaluated once, and those results will be cached for all subsequent requests.
serializer_class - The serializer class that should be used for validating and deserializing input, and for serializing output. Typically, you must either set this attribute, or override the get_serializer_class() method.
lookup_field - The model field that should be used to for performing object lookup of individual model instances. Defaults to 'pk'. Note that when using hyperlinked APIs you'll need to ensure that both the API views and the serializer classes set the lookup fields if you need to use a custom value.
REST framework permissions also support object-level permissioning. Object level permissions are used to determine if a user should be allowed to act on a particular object, which will typically be a model instance.
Object level permissions are run by REST framework's generic views when .get_object() is called. As with view level permissions, an exceptions.PermissionDenied exception will be raised if the user is not allowed to act on the given object.
If you're writing your own views and want to enforce object level permissions, or if you override the get_object method on a generic view, then you'll need to explicitly call the .check_object_permissions(request, obj) method on the view at the point at which you've retrieved the object.
check_password(password, encoded)
make_password(password, salt=None, hasher='default')
is_password_usable(encoded_password)
In this article, we explain verbose_name and verbose_name_plural in Django.
So both verbose_name and verbose_name_plural are ways of making objects human readable or converting to a point where they are human readable.
A notable place where verbose_name and verbose_name_plural can apply to is objects in a database table.
In Python, all rows of data in a database table are objects.
In Python, pretty much almost everything is an object, including strings, integers, and so on.