Как лучше описывать Generic View в Django? в файлах urls.py или во views.py
Добрый день, дорогие пользователи EVILEG!
Вот и я решил задать вопрос на своём форуме. Надеюсь на отклик. Давайте обсудим один вопрос.
Мне не даёт покоя одна мысль, где лучше прописывать Generic вьюшки в Django.
В документации есть два варианта, как использовать Generic вьюшки.
Первый вариант . Прописать всю информацию в Generic вьюшке прямо в файле urls.py
from django.urls import path from django.views.generic import TemplateView urlpatterns = [ path('about/', TemplateView.as_view(template_name="about.html")), ]
Второй вариант . Наследоваться от Generic вьюшки, описать параметры во views.py, а потом уже подключить эту вьюшку в файле urls.py
views.py
from django.views.generic import TemplateView class MyView(TemplateView): template_name = "about.html"
urls.py
from django.urls import path from myapp.views import MyView urlpatterns = [ path('about/', MyView.as_view()), ]
Мне не даёт покоя одна мысль, даёт ли какой-то бонус в производительности или потреблении памяти, если наследоваться от Generic вьюшки, когда нужно переопределить 5-6 атрибутов, да или даже всего 1 атрибут. Или лучше сразу прописывать всё как в первом варианте прямо в urls.py. Или это скорее уже вопрос код стайла, который имеется внутри команды разработчиков?
Кто-нибудь задавлся подобным вопросом или проводил тесты подобного вопроса?
We recommend hosting TIMEWEB
Stable hosting, on which the social network EVILEG is located. For projects on Django we recommend VDS hosting.Do you like it? Share on social networks!
- Akiv Doros
- Nov. 11, 2024, 7:58 p.m.
C ++ - Test 004. Pointers, Arrays and Loops
- Result:50points,
- Rating points-4
- molni99
- Oct. 26, 2024, 6:37 a.m.
C ++ - Test 004. Pointers, Arrays and Loops
- Result:80points,
- Rating points4
- molni99
- Oct. 26, 2024, 6:29 a.m.
C ++ - Test 004. Pointers, Arrays and Loops
- Result:20points,
- Rating points-10
Вообще, выигрыша никакого не получится, поскольку все инициализируется в один момент (загрузки приложения), а не on-demand, как PHP. Однако, архитектурно, более правильным вариантом я считаю - наследование. Поскольку, чуть позже, если захочется развить эту вьюху, все равно придется выносить в отдельный модуль.
Вот и я склоняюсь к решению с наследованием, тем более, что когда нужно описать 5-6 атрибутов, то файл urls.py становится менее красивым, чем хотелось бы.
Но сам по себе вопрос возник из того, что я стараюсь разрабатывать сайт абстрагируясь от конкретных реализаций контента, таким образом имеется одна общая часть, которая работает одинаково для статьей, комментариев, разделов, сообщений на форуме и т.д. В итоге появляется один кастомный GenericView, который благодаря метамагии Python обрабатывает сразу 5-6 url в файле urls.py для всех этих типов контента, и будет обрабатывать в будущем ещё 10, 20 да сколько потребуется.
Вот и возникает вопрос. Писать на каждый url свою вьюшку или оставить всю инициализацию в urls.py.
Хотя если всё прописать в views.py, то чисто на взгляд проще будет отрефакторить, поскольку код там читабельнее, но в итоге рефакторинг приведёт к тому, что появится новый GenericView, который будет описываться в urls.py и всё по новому...
Я так постоянно хожу по кругу с рефакторингом...
Явное лучше, чем не явное.
не надо экономить байты кода=)
а по поводу урлов - ради абстракции их можно хранить же вместе с представлением. и и любом другом проекте можно будет сделать include('....urls').
а что обрабатывает GenericView? может быть было бы правильнее вынести это в middleware, а сами вьюхи оставить чистыми?
Эти дженерики у меня обрабатывают формирование запроса в зависимости от модели данных и подставновку нужных шаблонов для формирования ListView объектов.
Но там есть ещё и немного JavaScript, который отвечает за частичную загрузку страницы при пагинации. Это реализовано для активностей, подписок и избранного в личном профиле пользователя, при пагинации на главной странице сайта. И ещё кое-где.
Поэтому не думаю, что это тот функционал, который имеет смысл выносить в middleware...
я не до конца понял - без кода сложно. в целом, я считаю, что мета-программирование - такое себе занятие. и нужно быть КРАЙНЕ осторожным с его применением=) а то насмотрелся=))) отлаживать, или, простихоспади, исправлять что-то - превращается в адовый ад=)
После дебага шаблонов на Qt/C++ с сигналами и слотами мета-программирование на Python мне не кажется таким уже сложным )))
Но согласен, что здесь нужно подходить осторожно. Я мета-программирование со всякими getattr , __name__ , __class__ применяю только для реализации общего, по факту библиотечного функционала, но это требует, чтобы код вылежался до стабильного состояния. Я поэтому медленно вывожу базовые исходники сайта в ESNF-C . По сути считаю весь не выведенный в Open Source функционал в качестве pre-alpha unstable .
не, __name__, __class__ и все прочее - еще пока даже не мета-программирование. я имею в виду создание классов и функций на летуне по шаблону, а на основе каких-то миксинов или того хуже - из ничего. а то был у меня опыт писать возможность расширения функционала - был создан базовый класс, от которого надо было наследоваться другому человеку и несколько статических параметров, типа url-а и названия страницы. человек описывал нужное, описывал нужную выделенную логику. а в момент инициализации сервера строилось дерево URL-ов и связанные вьюхи. такое себе, конечно, но по другому было бы сложно - человек не умел в джангу. а так ему надо было все описывать в одном месте.
Не, ну это конечно треш... такая шаблонизация - это что-то из ряда вон выходящее...
Как бы шаблонная логика на проверке наличия тех или иных атрибутов - это одно, а если создавать классы из "чего-то" просто потому, что другой человек не умеет этого чего-то сам - это конечно что-то из ряда вон выходящее... Я за адекватные шаблоны!