Oct. 8, 2018, 9:16 a.m.

Как лучше описывать Generic View в Django? в файлах urls.py или во views.py

Django, urls, views, Generic

Добрый день, дорогие пользователи 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
We recommend hosting TIMEWEB
Stable hosting, on which the social network EVILEG is located. For projects on Django we recommend VDS hosting.
8

Вообще, выигрыша никакого не получится, поскольку все инициализируется в один момент (загрузки приложения), а не on-demand, как PHP. Однако, архитектурно, более правильным вариантом я считаю - наследование. Поскольку, чуть позже, если захочется развить эту вьюху, все равно придется выносить в отдельный модуль.

0

Вот и я склоняюсь к решению с наследованием, тем более, что когда нужно описать 5-6 атрибутов, то файл urls.py становится менее красивым, чем хотелось бы.

Но сам по себе вопрос возник из того, что я стараюсь разрабатывать сайт абстрагируясь от конкретных реализаций контента, таким образом имеется одна общая часть, которая работает одинаково для статьей, комментариев, разделов, сообщений на форуме и т.д. В итоге появляется один кастомный GenericView, который благодаря метамагии Python обрабатывает сразу 5-6 url в файле urls.py для всех этих типов контента, и будет обрабатывать в будущем ещё 10, 20 да сколько потребуется.

Вот и возникает вопрос. Писать на каждый url свою вьюшку или оставить всю инициализацию в urls.py.

Хотя если всё прописать в views.py, то чисто на взгляд проще будет отрефакторить, поскольку код там читабельнее, но в итоге рефакторинг приведёт к тому, что появится новый GenericView, который будет описываться в urls.py и всё по новому...

Я так постоянно хожу по кругу с рефакторингом...


0

Явное лучше, чем не явное.

не надо экономить байты кода=)

а по поводу урлов - ради абстракции их можно хранить же вместе с представлением. и и любом другом проекте можно будет сделать include('....urls').


а что обрабатывает GenericView? может быть было бы правильнее вынести это в middleware, а сами вьюхи оставить чистыми?

0

Эти дженерики у меня обрабатывают формирование запроса в зависимости от модели данных и подставновку нужных шаблонов для формирования ListView объектов.

Но там есть ещё и немного JavaScript, который отвечает за частичную загрузку страницы при пагинации. Это реализовано для активностей, подписок и избранного в личном профиле пользователя, при пагинации на главной странице сайта. И ещё кое-где.

Поэтому не думаю, что это тот функционал, который имеет смысл выносить в middleware...


0

я не до конца понял - без кода сложно. в целом, я считаю, что мета-программирование - такое себе занятие. и нужно быть КРАЙНЕ осторожным с его применением=) а то насмотрелся=))) отлаживать, или, простихоспади, исправлять что-то - превращается в адовый ад=)

0

После дебага шаблонов на Qt/C++ с сигналами и слотами мета-программирование на Python мне не кажется таким уже сложным )))

Но согласен, что здесь нужно подходить осторожно. Я мета-программирование со всякими getattr , __name__ , __class__ применяю только для реализации общего, по факту библиотечного функционала, но это требует, чтобы код вылежался до стабильного состояния. Я поэтому медленно вывожу базовые исходники сайта в ESNF-C . По сути считаю весь не выведенный в Open Source функционал в качестве pre-alpha unstable .

0

не, __name__, __class__ и все прочее - еще пока даже не мета-программирование. я имею в виду создание классов и функций на летуне по шаблону, а на основе каких-то миксинов или того хуже - из ничего. а то был у меня опыт писать возможность расширения функционала - был создан базовый класс, от которого надо было наследоваться другому человеку и несколько статических параметров, типа url-а и названия страницы. человек описывал нужное, описывал нужную выделенную логику. а в момент инициализации сервера строилось дерево URL-ов и связанные вьюхи. такое себе, конечно, но по другому было бы сложно - человек не умел в джангу. а так ему надо было все описывать в одном месте.

0

Не, ну это конечно треш... такая шаблонизация - это что-то из ряда вон выходящее...

Как бы шаблонная логика на проверке наличия тех или иных атрибутов - это одно, а если создавать классы из "чего-то" просто потому, что другой человек не умеет этого чего-то сам - это конечно что-то из ряда вон выходящее... Я за адекватные шаблоны!



0

Comments

Only authorized users can post comments.
Please, Log in or Sign up
Last comments
June 24, 2019, 10:23 a.m.
Евгений Легоцкой

Хорошо, ну будут проблемы помимо того, что касается статей, то не стесняйтесь задавать вопросы на форуме.
МБ
June 24, 2019, 10:21 a.m.
Михаил Булатов

Извиняюсь, все работает(из-за невнимательности).
June 24, 2019, 9:52 a.m.
Евгений Легоцкой

Придётся делать ещё сигнал в дочернем qml и пробрасывать через коннекты и обработчики. А вообще нужно смотреть конкретный код и что вы пытаетесь сделать. Так что лучше будет, если вы зад...
June 21, 2019, 8:31 a.m.
Ruslan Polupan

Вот моя строка по которой все отлично сработало %cqtdeployer% -bin c:/CentralMposKeys/CentalMposKeys.exe -qmake c:/Qt/5.12.2/mingw73_64/bin/qmake.exe
June 21, 2019, 8:24 a.m.
Андрей Янкович

Возможно кому то пригодится сqtdeployer для windows работает точно так же как и для Linux разница лишь в команде запуска Linux: cqtdeployer Windows: %cqtdeployer...
Now discuss on the forum
June 24, 2019, 2:36 p.m.
Михаиллл

Нашел проект подключения к вебсокету.Но по моему адресу не могу подключиться.Нужно ли для этого использовать библиотеки?Вы не знаете адрес вебсокета, на котором можно проверить с...
June 24, 2019, 2:07 p.m.
Евгений Легоцкой

Я пока даже не знаю, а какой код самого подключения? использовали ожидание на подключение? Так делали? socket->connectToServer("market");if (socket->waitForConnected(1000)) ...
June 24, 2019, 1:19 p.m.
IscanderChe

// widget.cpp#include "widget.h"#include <QTableView>#include <QVBoxLayout>#include "checkboxdelegate.h"#include "comboboxdelegate.h"#include "mytableview.h"#include <QSqlD...
June 24, 2019, 11:16 a.m.
BlinCT

Хорошо, с этим понятно. Вот есть такой набор каких то кнопок. Цифры отображают в каком порядке должен менятся фокус.1. Как правильнее сделать отображение активного обьекта...
e
June 24, 2019, 10:58 a.m.
evgenm27

Спасибо за ответ, буду пробовать
Looking for a Job?
10,000.00 руб. - 15,000.00 руб.
Нужен помощник для создания API.
Moscow, Moscow, Russia
25,000.00 руб. - 30,000.00 руб.
Разработчик Qt/C++
Barnaul, Altai Krai, Russia

For registered users on the site there is a minimum amount of advertising

EVILEG
About
Services
Join us
© EVILEG 2015-2019
Recommend hosting TIMEWEB