При работе с Django/Django Rest Framework я заметил несогласованность доступа к параметрам URL в представлениях на основе классов.
Описание проблемы
В представлениях на основе универсальных классов я могу получить доступ к параметрам URL-адреса двумя разными способами — в зависимости от метода:
Через позиционные аргументы:
Например, в методе get я могу получить доступ к параметрам URL-адреса как позиционным аргументам, передаваемым непосредственно в метод:
#views.py
class MyView(ListView):
model = MyModel
def get_queryset(self):
param1 = self.kwargs.get('param1')
param2 = self.kwargs.get('param2')
return MyModel.objects.filter(field1=param1, field2=param2)
Я знаю, что могу получить доступ к параметрам URL из kwargs где угодно, но это приводит меня к некоторым вопросам
Мои вопросы:
Почему Django/DRF не представил специальный атрибут для параметров URL? Не было бы более интуитивно понятным хранить эти параметры в специальном атрибуте, таком как self.url_params - есть ли какие-то конкретные причины, по которым предпочтительным является именование self.kwargs - я понял соглашение, но это немного Меня это сбивает с толку, у нас есть много других атрибутов, таких как idk self.data или self.method, но у нас нет атрибутов URL.
< li>Почему Механизм self.kwargs не описан явно в документации Django. У меня немного болела голова, когда я пытался понять, почему. Кажется, этот механизм имеет решающее значение для работы с представлениями на основе классов, но я не смог найти четкого объяснения, почему это так. Вместо этого в документации приводятся только примеры, по-видимому, ожидающие, что разработчики «сделают вывод», что параметры URL-адреса хранятся в self.kwargs.
Может кто-нибудь пролить свет на то, почему это так? Буду признателен за любые идеи и объяснения этого дизайнерского решения.
При работе с Django/Django Rest Framework я заметил несогласованность доступа к параметрам URL в представлениях на основе классов.
Описание проблемы В представлениях на основе универсальных классов я могу получить доступ к параметрам URL-адреса двумя разными способами — в зависимости от метода: [list] [*] Через позиционные аргументы: Например, в методе get я могу получить доступ к параметрам URL-адреса как позиционным аргументам, передаваемым непосредственно в метод: [/list] [code]#urls.py path('test///', MyView.as_view()) [/code] [code]#views.py class MyView(View): def get(self, request, param1, param2): return JsonResponse({'param1': param1, 'param2': param2}) [/code] [list] [*]Через атрибут self.kwargs Например, когда я хочу получить доступ к тем же параметрам в get_queryset< /code>, мне нужно использовать self.kwargs [/list] [code]#views.py class MyView(ListView): model = MyModel
def get_queryset(self): param1 = self.kwargs.get('param1') param2 = self.kwargs.get('param2') return MyModel.objects.filter(field1=param1, field2=param2) [/code] Я знаю, что могу получить доступ к параметрам URL из kwargs где угодно, но это приводит меня к некоторым вопросам Мои вопросы: [list] [*]Почему Django/DRF не представил специальный атрибут для параметров URL? Не было бы более интуитивно понятным хранить эти параметры в специальном атрибуте, таком как self.url_params - есть ли какие-то конкретные причины, по которым предпочтительным является именование self.kwargs - я понял соглашение, но это немного Меня это сбивает с толку, у нас есть много других атрибутов, таких как idk self.data или self.method, но у нас нет атрибутов URL. < li>Почему Механизм self.kwargs не описан явно в документации Django. У меня немного болела голова, когда я пытался понять, почему. Кажется, этот механизм имеет решающее значение для работы с представлениями на основе классов, но я не смог найти четкого объяснения, почему это так. Вместо этого в документации приводятся только примеры, по-видимому, ожидающие, что разработчики «сделают вывод», что параметры URL-адреса хранятся в self.kwargs. [/list]
Может кто-нибудь пролить свет на то, почему это так? Буду признателен за любые идеи и объяснения этого дизайнерского решения.